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

From: Brian Rosen ^lt;br@brianrosen.net>
Date: Thu Jul 20 2006 - 18:11:19 EDT

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:sedge@qualcomm.com]
Sent: Thursday, July 20, 2006 2:20 AM
To: geopriv@ietf.org
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.
 
Thanks in advance for any replies.
 
Kind Regards
 
Stephen

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Thu, 20 Jul 2006 18:11:19 -0400

This archive was generated by hypermail 2.1.8 : Thu Jul 20 2006 - 18:25:51 EDT