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

From: "Brian Rosen" <[email-masked]>
Date: Fri, 21 Jul 2006 10:28:59 -0400

Well, there seems to be some differences of opinion on what happens with PS
emergency calls in 3GPP, but regardless, I think we have the ground covered.

The general direction for IETF support of emergency calling is that the
access network tells the endpoint where it is, and the endpoint tells the
PSAP where it is (also the routing element).  The reason we do that is that
the general case is that the access network and the SIP routing network may
have no relationship with one another.  Consider, for example, a broadband
network, which may well have an IMS implementation providing voice calling
services, but other, non-IMS calling services may be used by the consumer.
The access network in that circumstance has no knowledge of the emergency
call; it is just providing a packet service.  The endpoint however, is the
client of BOTH the access network and the SIP signaling network, and thus is
in the best position to hand location from one network to another.

However, we know that there are circumstances where the access network and
the SIP signaling network are the same network, or have an existing
relationship which would allow the SIP signaling network to assert location
on the call, and use it for routing.  This involves a proxy placing a URI in
a SIP header that refers to the location.  Network asserted location IS
supported in the IETF framework.

Location update can either be accomplished by using a location reference and
repeatedly de-referencing it, or by subscribing to an update service.

Now, with respect to your draft, the call would originate from an endpoint
who did not supply location.  It would be sent to a proxy that would add a
location reference as a SIP Location Header.  That element could also
perform the routing, based on the location, or the call could be forwarded
to another SIP element which would do the routing.  The call would arrive at
the PSAP with location attached as the aforementioned location reference,
assuming the PSAP was IP capable.  The PSAP could, depending on the form of
the reference, repeatedly de-reference it, or subscribe to location updates.

In a PS domain emergency call to a non IP capable PSAP, the location would
be used by a gateway element to provide the existing emergency call system
with location.  In the U.S. for example, if the call were treated as a VoIP
call, it would be forwarded to a VPC, which would extract the location
reference from the SIP signaling, use it to obtain location, determine the
PSAP that gets the call based on the location, choose an appropriate ESQK,
forward the call to the correct ESGW, which would connect the call to the
right SR, using the ESQK as ANI.  The PSAP would get the call from the SR,
query ALI with the ANI (ESQK), which would be steered to the right VPC,
which would respond with the location.  Sorry for the acronym density for
those reading this not up on U.S. VoIP 9-1-1.

At no time did any element need to know if A-GPS or A-FLT were possible
choices.

In an IP capable PSAP, the location dereference would use an IETF protocol
(SIP, or the L7 protocol under development in geopriv).  In a VoIP call with
a non-upgraded PSAP, the gateway element (the VPC in the U.S.) would do the
same. The element that provides the dereference service MAY use some other
protocol to get location, but that would be known by that element (because
the network that provided the reference is the network that has the location
determination mechanisms).

So, I'm back to not understanding what the draft does that we haven't
already dealt with.

Brian

________________________________________
From: Edge, Stephen [mailto:[email-masked]] 
Sent: Friday, July 21, 2006 2:29 AM
To: Brian Rosen; [email-masked]
Subject: RE: [Geopriv] draft-hdesinen-geopriv-pidflo-extn-00.txt

Hi Brian and others
Thanks for the comments which I can see are based on assumptions about how
emergency VoIP calls will be supported. Unfortunately, many of the
assumptions will not apply to 3GPP wireless networks and probably not to
3GPP2 networks. Mainly, the location used for routing will not always be
provided by the endpoint but will in some cases need to be obtained by the
network and the location provided to the PSAP will generally be obtained by
(or at least requested by) the network in case of an initial location and
will always be thus obtained or requested in the case of an updated
location. This is how emergency calls are supported today and it is how the
current 3GPP VoIP based solution and expected 3GPP2 solutions will also
work. (Reasons for this include an inability generally to obtain accurate
location at the time an emergency call is sent and no requirement and in
some cases no ability for an endpoint to initiate location update
subsequently.) If the network (routing proxy, location/routing server or LIS
surrogate) does not know the location solutions (location acquisition
protocols) and position methods supported by the endpoint, then the
derivation of location will occur in a sub-optimal manner – e.g. by trying a
protocol or assuming a location method not supported by the endpoint. Maybe
in the future when all PSAPs are IP capable and network architectures and
procedures conform to Ecrit assumptions, the situation will be different,
but that is probably a long time away. For the near term, we need some
method to provide the supported location solutions and position methods. The
pidf-lo extension seemed to be the simplest choice, although I am sure there
are alternatives.
Kind Regards
Stephen
•       To: "'Edge, Stephen'" <sedge at qualcomm.com>, <geopriv at ietf.org>

•       Subject: RE: [Geopriv] draft-hdesinen-geopriv-pidflo-extn-00.txt 
•       From: "Brian Rosen" <br at brianrosen.net> 
•       Date: Thu, 20 Jul 2006 18:11:19 -0400 
•       Cc: 
•       In-reply-to:
<[email-masked]> 
•       List-help: <mailto:[email-masked]?subject=help> 
•       List-id: Geographic Location/Privacy <geopriv.ietf.org> 
•       List-post: <mailto:[email-masked]> 
•       List-subscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>,
<mailto:[email-masked]?subject=subscribe> 
•       List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>,
<mailto:[email-masked]?subject=unsubscribe> 
•       Thread-index: AcarxJWRRzIZFnxJQWyJEWRGPIdAqgAf6vhQ 
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 at qualcomm.com] 
Sent: Thursday, July 20, 2006 2:20 AM
To: geopriv at 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Ted Hardie <[email-masked]>
Date: Fri, 21 Jul 2006 10:56:00 -0700

At 10:28 AM -0400 7/21/06, Brian Rosen wrote:
>PSAP where it is (also the routing element).

As I've pointed out before, there are cases where the endpoint knows
its location without reference to an access network action; it may know
it because of a location technology (e.g. GPS) unrelated to the network.

The key point in all of the mass I've elided below is that we don't want
to have to invent relationships among providers.  There are cases where
the access network and voice service provider are the same; there are cases
where they have existing business agreements; there are cases where they do
not.  The only consistent, unifying aspect of their interaction is that they share
a customer.  Making it possible for the customer to be the conduit for any
interaction eliminates creating or modifying existing business agreements.

None of that prevents any additional interaction when the two networks
are the same or have an existing relationship; it simply establishes a baseline
that will work whether they do or don't.

				Ted Hardie

---

From: "Edge, Stephen" <[email-masked]>
Date: Fri, 21 Jul 2006 16:05:19 -0700

Hi Brian and others who have commented

Thanks again for the responses, even though progress seems rather slow! Also thanks for the explanation concerning how location support and routing are supposed to work which seems to be mostly based on the NENA I2 standard for fixed and nomadic users. If these were the only users, I would agree less need for the solution we are proposing (though it could still be useful). But for wireless users, what is being proposed will not work. If you refer to the latest 3GPP stage 2 definition for support of IMS emergency calls (ftp://ftp.3gpp.org/Specs/archive/23_series/23.167/23167-710.zip which I would attach here with highlighting if message size limits permitted) you will find substantiation of what I am saying.

Here are 2 examples which illustrate why location of wireless endpoints is different.

Example 1

A user accessing a WCDMA (3GPP) visited network makes an E911 call. Both the UE (handset) and visited network support enhanced cell ID positioning and A-GPS using SUPL 2.0 but not 3GPP control plane. The UE knows the serving cell ID when the call is placed but not its exact location. There is no time to perform accurate GPS (or A-GPS) positioning or request a position from the home network using SUPL and enhanced cell ID. The call (SIP INVITE) is sent to the visited network carrying the cell ID. The routing server (E-CSCF or LRF in the case of 3GPP) determines that 2 different PSAPs serve different portions of the cell. The E-CSCF or LRF has the option of choosing a PSAP randomly (e.g. choose the PSAP serving the larger or more highly populated cell portion) or attempting to obtain a more accurate location. If the E-CSCF or LRF does not know the location solutions supported by the UE and the position methods, no intelligent decision can be made. If the E-CSCF/LRF attempts SUPL location it will, in this case, be able to obtain a location using enhanced cell ID positioning which could be very fast and (by narrowing down the portion of the cell in which the user is located) would enable a more reliable routing choice. If the UE did not support SUPL or enhanced cell ID positioning, time would be wasted in a fruitless positioning attempt and routing will not be improved. At some later time, the PSAP may request an accurate location estimate. In the 3GPP architecture, the request is sent to the LRF (or to the E-CSCF if that functions as the LRF). Knowing that the UE supports SUPL and A-GPS, the LRF can confidently instigate accurate positioning. Without that knowledge, the LRF could still make an attempt but would be forced to provide a phase 1 location estimate based on the original cell ID if the UE did not support SUPL. This is also the result if the LRF knows in advance that the UE does not support SUPL except that the response to the PSAP can be faster (e.g. allowing the PSAP extra time to query the user). Note that a location based on cell ID would not normally be sent to a PSTN capable PSAP together with call signaling because the additional signaling is not commonly supported by PSAPs and networks.

Example 2

A user accessing a cdma2000 Ev-DO visited network (3GPP2) supports SUPL 1.0 (but not SUPL 2.0) and A-GPS. The visited network supports SUPL 1.0, SUPL 2.0, A-GPS and enhanced cell ID. The PSAP/cell situation is as in (1). In this case, if the E-CSCF/LRF (or whatever will be defined in 3GPP2 in place of these) knows the UE capabilities, it can avoid making a fruitless attempt to obtain a more accurate location for routing using enhanced cell ID. Without this knowledge, some implementations might waste time doing this (e.g. if most VoIP capable phones support SUPL 2.0). If the PSAP later requests an accurate location, the E-CSCF/LRF can avoid trying SUPL 2.0 which will just waste time. (Note that SUPL 2.0 allows a visited network to directory instigate positioning of a UE for an emergency call; with SUPL 1.0 only the home network can instigate positioning.) However, if there is a suitable roaming agreement between the visited and home networks, the E-CSCF/LRF can still obtain a location by sending a request to the home network (actually to an H-SLP in the home network). This would be justified based on knowledge of support for SUPL 1.0 and A-GPS (e.g. it might not be justified if only enhanced cell ID was supported or if SUPL 1.0 was not supported).

I have also embedded some further comments below (look for "-->"). Hopefully, this will show why these enhancements are needed.

Kind Regards

Stephen
-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, July 21, 2006 7:29 AM
To: Edge, Stephen; [email-masked]
Subject: RE: [Geopriv] draft-hdesinen-geopriv-pidflo-extn-00.txt

--> SE: a 3GPP or 3GPP2 access network will generally not tell the endpoint where it is. A WLAN may be able to give the endpoint its location, but that may not be very accurate (unless 802.11v positioning, for example, is supported). Location will also not generally be sent directly to a PSTN capable PSAP with call signaling due to lack of implementation support for ISUP signaling and no location transfer capability with MF.

--> SE: location references (e.g. to a LIS) will not generally be used in the 3GPP solution which is based on obtaining location through a real time location procedure involving the serving network and endpoint.

--> SE: this is not part of the 3GPP solution

--> SE: the wireless endpoint would provide whatever location it had or its current cell ID. An ESQK identifier could be provided to the PSAP.

--> SE: this seems to be a summary of the NENA I2 solution, which is not sufficient for wireless and has been effectively modified and enhanced in the 3GPP solution (and most likely same for 3GPP2 although that is still only defined at a stage 1 level)

--> SE: as shown in the previous examples, this type of knowledge can be useful. Of course, if you assume that the initial location information (e.g. cell ID) maps unambiguously to a single PSAP and is accurate enough for the PSAP (without the need for re-positioning), then the additional information is not needed. That may often be the case for nomadic subscribers (whose location could be obtained from a wireline based access network and won't change subsequently) but it won't normally apply to wireless users where location won't typically be available from the access network (without executing some positioning procedure) and may change.

--> SE: I am not sure that procedures for location retrieval by an IP capable PSAP are yet known - e.g. it would be possible and probably desirable to reuse the existing NCAS procedure (used by PSTN capable PSAPs) defined in J-STD-036 for the US and in OMA MLP for some other regions. The use of SIP or some L7 protocol would mean upgrades for both PSAPs and wireless operators.

Brian

Hi Brian and others
derivation of location will occur in a sub-optimal manner - e.g. by trying a
*       To: "'Edge, Stephen'" <sedge at qualcomm.com>, <geopriv at ietf.org>

*       Subject: RE: [Geopriv] draft-hdesinen-geopriv-pidflo-extn-00.txt 
*       From: "Brian Rosen" <br at brianrosen.net> 
*       Date: Thu, 20 Jul 2006 18:11:19 -0400 
*       Cc: 
*       In-reply-to:
*       List-help: <mailto:[email-masked]?subject=help> 
*       List-id: Geographic Location/Privacy <geopriv.ietf.org> 
*       List-post: <mailto:[email-masked]> 
*       List-subscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>,
*       List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>,
*       Thread-index: AcarxJWRRzIZFnxJQWyJEWRGPIdAqgAf6vhQ 

 

 

 
Kind Regards
 
Stephen

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 21 Jul 2006 22:47:44 -0500

Stephen,
 
I think some of what you describe below is simply a misunderatnding of what a LIS is.
The LIS is the node in the serving access network responsible for location determination. This may be a wiremap, but does not have to be. It can be a broker to other determination mechanisms in much the same way an SMLC may use different determination technologies. Futher more to suggest that i2 is not mobile capable demonstrates a misunderstanding of the architecture, the V3 interface in i2 was specifically put in place to provide mobile support and location updates.
 
If you make use of an access network, like it or not you enter into a relationship with it. I agree whole heartedly with Brian here that the relationship for capabilities should be between the LIS and the end-point. These capabilities should be exchanged upon entry to the network in a manner designed for capability exchange and not bolted into something that is designed to convey your location in a presence document.
 
Your arguements merely point to the Achilles's heel of SUPL in terms of relying solely on the voice provider for determining location. The architectures proposed in i2 and i3 place this responsibility on access provider who ultimately has control over how an end-point attaches to the network.
 
Cheers
James

________________________________

From: Edge, Stephen [mailto:[email-masked]]
Sent: Fri 21/07/2006 6:05 PM
To: Brian Rosen; [email-masked]
Subject: RE: [Geopriv] draft-hdesinen-geopriv-pidflo-extn-00.txt

Example 1

Example 2

Kind Regards

Stephen
-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Friday, July 21, 2006 7:29 AM
To: Edge, Stephen; [email-masked]
Subject: RE: [Geopriv] draft-hdesinen-geopriv-pidflo-extn-00.txt

Brian

Hi Brian and others

 

 

 
 
Kind Regards
 
Stephen

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

---

From: "Edge, Stephen" <[email-masked]>
Date: Sat, 22 Jul 2006 02:18:27 -0700

Hi James

Thanks for the response and clarifications. However, I didn't think we
were discussing the pro.s and con.s of alternative location solutions
and their related architectures (at least not until now). I agree that
if the endpoint and LIS can flexibly interact to produce location (at
any point in time) and if, in the process, the LIS can obtain the
location capabilities of the endpoint, then using a NENA type of
solution, it should be possible to support VoIP emergency calls without
our proposal (since the proposal would already be supported in a
different manner).

Of course, such an alternative solution would have significant impacts
to existing wireless networks (and endpoints) little of which would be
necessary if the existing 3GPP/3GPP2 envisaged solution was retained
(built as it is on location capabilities already defined and being
deployed). 

So the comparison would become BIG 3GPP/3GPP2 location impact + NO
Geopriv impact versus MUCH SMALLER 3GPP/3GPP2 location impact + SMALL
geopriv impact.

(There might also be an issue as to whether a different 3GPP/3GPP2
location solution based on the NENA/Ecrit model was actually effective
for other uses since it resembles the existing control plane solutions
which have certain limitations. However this kind of evaluation might
not be possible until the solution had been defined in considerably
greater detail in the context of different types of wireless network.
And until that was done, any guess could be made as to expected benefits
and drawbacks.)

Please comment on this.

Kind Regards

Stephen
-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Friday, July 21, 2006 8:48 PM
To: Edge, Stephen; Brian Rosen; [email-masked]
Subject: RE: [Geopriv] draft-hdesinen-geopriv-pidflo-extn-00.txt

Stephen,
 
I think some of what you describe below is simply a misunderatnding of
what a LIS is.
The LIS is the node in the serving access network responsible for
location determination. This may be a wiremap, but does not have to be.
It can be a broker to other determination mechanisms in much the same
way an SMLC may use different determination technologies. Futher more to
suggest that i2 is not mobile capable demonstrates a misunderstanding of
the architecture, the V3 interface in i2 was specifically put in place
to provide mobile support and location updates.
 
If you make use of an access network, like it or not you enter into a
relationship with it. I agree whole heartedly with Brian here that the
relationship for capabilities should be between the LIS and the
end-point. These capabilities should be exchanged upon entry to the
network in a manner designed for capability exchange and not bolted into
something that is designed to convey your location in a presence
document.
 
Your arguements merely point to the Achilles's heel of SUPL in terms of
relying solely on the voice provider for determining location. The
architectures proposed in i2 and i3 place this responsibility on access
provider who ultimately has control over how an end-point attaches to
the network.
 
Cheers
James

Thanks again for the responses, even though progress seems rather slow!
Also thanks for the explanation concerning how location support and
routing are supposed to work which seems to be mostly based on the NENA
I2 standard for fixed and nomadic users. If these were the only users, I
would agree less need for the solution we are proposing (though it could
still be useful). But for wireless users, what is being proposed will
not work. If you refer to the latest 3GPP stage 2 definition for support
of IMS emergency calls
(ftp://ftp.3gpp.org/Specs/archive/23_series/23.167/23167-710.zip which I
would attach here with highlighting if message size limits permitted)
you will find substantiation of what I am saying.

Here are 2 examples which illustrate why location of wireless endpoints
is different.

Example 1

A user accessing a WCDMA (3GPP) visited network makes an E911 call. Both
the UE (handset) and visited network support enhanced cell ID
positioning and A-GPS using SUPL 2.0 but not 3GPP control plane. The UE
knows the serving cell ID when the call is placed but not its exact
location. There is no time to perform accurate GPS (or A-GPS)
positioning or request a position from the home network using SUPL and
enhanced cell ID. The call (SIP INVITE) is sent to the visited network
carrying the cell ID. The routing server (E-CSCF or LRF in the case of
3GPP) determines that 2 different PSAPs serve different portions of the
cell. The E-CSCF or LRF has the option of choosing a PSAP randomly (e.g.
choose the PSAP serving the larger or more highly populated cell
portion) or attempting to obtain a more accurate location. If the E-CSCF
or LRF does not know the location solutions supported by the UE and the
position methods, no intelligent decision can be made. If the E-CSCF/LRF
attempts SUPL location it will, in this case, be able to obtain a
location using enhanced cell ID positioning which could be very fast and
(by narrowing down the portion of the cell in which the user is located)
would enable a more reliable routing choice. If the UE did not support
SUPL or enhanced cell ID positioning, time would be wasted in a
fruitless positioning attempt and routing will not be improved. At some
later time, the PSAP may request an accurate location estimate. In the
3GPP architecture, the request is sent to the LRF (or to the E-CSCF if
that functions as the LRF). Knowing that the UE supports SUPL and A-GPS,
the LRF can confidently instigate accurate positioning. Without that
knowledge, the LRF could still make an attempt but would be forced to
provide a phase 1 location estimate based on the original cell ID if the
UE did not support SUPL. This is also the result if the LRF knows in
advance that the UE does not support SUPL except that the response to
the PSAP can be faster (e.g. allowing the PSAP extra time to query the
user). Note that a location based on cell ID would not normally be sent
to a PSTN capable PSAP together with call signaling because the
additional signaling is not commonly supported by PSAPs and networks.

Example 2

A user accessing a cdma2000 Ev-DO visited network (3GPP2) supports SUPL
1.0 (but not SUPL 2.0) and A-GPS. The visited network supports SUPL 1.0,
SUPL 2.0, A-GPS and enhanced cell ID. The PSAP/cell situation is as in
(1). In this case, if the E-CSCF/LRF (or whatever will be defined in
3GPP2 in place of these) knows the UE capabilities, it can avoid making
a fruitless attempt to obtain a more accurate location for routing using
enhanced cell ID. Without this knowledge, some implementations might
waste time doing this (e.g. if most VoIP capable phones support SUPL
2.0). If the PSAP later requests an accurate location, the E-CSCF/LRF
can avoid trying SUPL 2.0 which will just waste time. (Note that SUPL
2.0 allows a visited network to directory instigate positioning of a UE
for an emergency call; with SUPL 1.0 only the home network can instigate
positioning.) However, if there is a suitable roaming agreement between
the visited and home networks, the E-CSCF/LRF can still obtain a
location by sending a request to the home network (actually to an H-SLP
in the home network). This would be justified based on knowledge of
support for SUPL 1.0 and A-GPS (e.g. it might not be justified if only
enhanced cell ID was supported or if SUPL 1.0 was not supported).

I have also embedded some further comments below (look for "-->").
Hopefully, this will show why these enhancements are needed.

Kind Regards

Stephen
-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Friday, July 21, 2006 7:29 AM
To: Edge, Stephen; [email-masked]
Subject: RE: [Geopriv] draft-hdesinen-geopriv-pidflo-extn-00.txt

Well, there seems to be some differences of opinion on what happens with
PS
emergency calls in 3GPP, but regardless, I think we have the ground
covered.

The general direction for IETF support of emergency calling is that the
access network tells the endpoint where it is, and the endpoint tells
the
PSAP where it is (also the routing element).  The reason we do that is
that
the general case is that the access network and the SIP routing network
may
have no relationship with one another.  Consider, for example, a
broadband
network, which may well have an IMS implementation providing voice
calling
services, but other, non-IMS calling services may be used by the
consumer.
The access network in that circumstance has no knowledge of the
emergency
call; it is just providing a packet service.  The endpoint however, is
the
client of BOTH the access network and the SIP signaling network, and
thus is
in the best position to hand location from one network to another.

--> SE: a 3GPP or 3GPP2 access network will generally not tell the
endpoint where it is. A WLAN may be able to give the endpoint its
location, but that may not be very accurate (unless 802.11v positioning,
for example, is supported). Location will also not generally be sent
directly to a PSTN capable PSAP with call signaling due to lack of
implementation support for ISUP signaling and no location transfer
capability with MF.

However, we know that there are circumstances where the access network
and
the SIP signaling network are the same network, or have an existing
relationship which would allow the SIP signaling network to assert
location
on the call, and use it for routing.  This involves a proxy placing a
URI in
a SIP header that refers to the location.  Network asserted location IS
supported in the IETF framework.

--> SE: location references (e.g. to a LIS) will not generally be used
in the 3GPP solution which is based on obtaining location through a real
time location procedure involving the serving network and endpoint.

Location update can either be accomplished by using a location reference
and
repeatedly de-referencing it, or by subscribing to an update service.

Now, with respect to your draft, the call would originate from an
endpoint
who did not supply location.  It would be sent to a proxy that would add
a
location reference as a SIP Location Header.  That element could also
perform the routing, based on the location, or the call could be
forwarded
to another SIP element which would do the routing.  The call would
arrive at
the PSAP with location attached as the aforementioned location
reference,
assuming the PSAP was IP capable.  The PSAP could, depending on the form
of
the reference, repeatedly de-reference it, or subscribe to location
updates.

--> SE: the wireless endpoint would provide whatever location it had or
its current cell ID. An ESQK identifier could be provided to the PSAP.

In a PS domain emergency call to a non IP capable PSAP, the location
would
be used by a gateway element to provide the existing emergency call
system
with location.  In the U.S. for example, if the call were treated as a
VoIP
call, it would be forwarded to a VPC, which would extract the location
reference from the SIP signaling, use it to obtain location, determine
the
PSAP that gets the call based on the location, choose an appropriate
ESQK,
forward the call to the correct ESGW, which would connect the call to
the
right SR, using the ESQK as ANI.  The PSAP would get the call from the
SR,
query ALI with the ANI (ESQK), which would be steered to the right VPC,
which would respond with the location.  Sorry for the acronym density
for
those reading this not up on U.S. VoIP 9-1-1.

--> SE: this seems to be a summary of the NENA I2 solution, which is not
sufficient for wireless and has been effectively modified and enhanced
in the 3GPP solution (and most likely same for 3GPP2 although that is
still only defined at a stage 1 level)

--> SE: as shown in the previous examples, this type of knowledge can be
useful. Of course, if you assume that the initial location information
(e.g. cell ID) maps unambiguously to a single PSAP and is accurate
enough for the PSAP (without the need for re-positioning), then the
additional information is not needed. That may often be the case for
nomadic subscribers (whose location could be obtained from a wireline
based access network and won't change subsequently) but it won't
normally apply to wireless users where location won't typically be
available from the access network (without executing some positioning
procedure) and may change.

In an IP capable PSAP, the location dereference would use an IETF
protocol
(SIP, or the L7 protocol under development in geopriv).  In a VoIP call
with
a non-upgraded PSAP, the gateway element (the VPC in the U.S.) would do
the
same. The element that provides the dereference service MAY use some
other
protocol to get location, but that would be known by that element
(because
the network that provided the reference is the network that has the
location
determination mechanisms).

--> SE: I am not sure that procedures for location retrieval by an IP
capable PSAP are yet known - e.g. it would be possible and probably
desirable to reuse the existing NCAS procedure (used by PSTN capable
PSAPs) defined in J-STD-036 for the US and in OMA MLP for some other
regions. The use of SIP or some L7 protocol would mean upgrades for both
PSAPs and wireless operators.

Brian

Hi Brian and others
Thanks for the comments which I can see are based on assumptions about
how
emergency VoIP calls will be supported. Unfortunately, many of the
assumptions will not apply to 3GPP wireless networks and probably not to
3GPP2 networks. Mainly, the location used for routing will not always be
provided by the endpoint but will in some cases need to be obtained by
the
network and the location provided to the PSAP will generally be obtained
by
(or at least requested by) the network in case of an initial location
and
will always be thus obtained or requested in the case of an updated
location. This is how emergency calls are supported today and it is how
the
current 3GPP VoIP based solution and expected 3GPP2 solutions will also
work. (Reasons for this include an inability generally to obtain
accurate
location at the time an emergency call is sent and no requirement and in
some cases no ability for an endpoint to initiate location update
subsequently.) If the network (routing proxy, location/routing server or
LIS
surrogate) does not know the location solutions (location acquisition
protocols) and position methods supported by the endpoint, then the
derivation of location will occur in a sub-optimal manner - e.g. by
trying a
protocol or assuming a location method not supported by the endpoint.
Maybe
in the future when all PSAPs are IP capable and network architectures
and
procedures conform to Ecrit assumptions, the situation will be
different,
but that is probably a long time away. For the near term, we need some
method to provide the supported location solutions and position methods.
The
pidf-lo extension seemed to be the simplest choice, although I am sure
there
are alternatives.
Kind Regards
Stephen
*       To: "'Edge, Stephen'" <sedge at qualcomm.com>, <geopriv at
ietf.org>

*       Subject: RE: [Geopriv] draft-hdesinen-geopriv-pidflo-extn-00.txt
*       From: "Brian Rosen" <br at brianrosen.net>
*       Date: Thu, 20 Jul 2006 18:11:19 -0400
*       Cc:
*       In-reply-to:
<[email-masked]>
*       List-help: <mailto:[email-masked]?subject=help>
*       List-id: Geographic Location/Privacy <geopriv.ietf.org>
*       List-post: <mailto:[email-masked]>
*       List-subscribe:
<https://www1.ietf.org/mailman/listinfo/geopriv>,
<mailto:[email-masked]?subject=subscribe>
*       List-unsubscribe:
<https://www1.ietf.org/mailman/listinfo/geopriv>,
<mailto:[email-masked]?subject=unsubscribe>
*       Thread-index: AcarxJWRRzIZFnxJQWyJEWRGPIdAqgAf6vhQ
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 at qualcomm.com]
Sent: Thursday, July 20, 2006 2:20 AM
To: geopriv at 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.

Kind Regards
 
Stephen

------------------------------------------------------------------------
------------------------
------------------------------------------------------------------------
------------------------
[mf2]

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 23 Jul 2006 19:50:00 -0500

Hi Stephen,

Based on my reading of 23.167, your(?) draft makes a little more sense now.  That isn't to say that I agree with its implementation.

23.167 makes a number of assumptions that do not hold in general.  This is generally true of IMS and the reason why those networks are less interesting for ECRIT/GEOPRIV:

 - The trust relationship between the home network and the visited network is assumed. When you have to deal with a separation of access provider and voice provider these systems don't work.  Brian and Ted have already made good points on this one.

 - The LRF (or E-CSCF) is given two distinct tasks.  The location determination task is combined with the route decision task.  This is obviously something that carries over from the roles performed by the GMLC for X-Y routing.  Based on a separation of access and service, I2/I3 do not make this assumption and identify two separate roles:
    : The LIS provides location information and exists in the access network.
    : The LoST server determines a route - it does not require any specific association, although the authoritative LoST server exists in the same jurisdiction as the Target.

Here is my alternative example, which deals with the above assumptions:

 1. The User initiates an emergency call.  (Note: We talk about emergency calling, but this procedure might also apply to a call to the local pizza delivery service.)

 2. The UE decides that it doesn't have enough time to determine location.  (Note that this really isn't a valid decision.  Location information is necessary for emergency routing - you can't save time by avoiding this step.)  There are a few possibilities here:
    a. The UE has relatively recent information available...it uses that.
    b. The UE can request location information from the LIS.  It indicates to the LIS that it is in a hurry.  It might include a Cell-ID in the request to provide assistance.  The LIS is a network element, so it can perform a few tricks to get location information quickly.
    c. The UE might already have a location reference...it uses that.
    d. The UE might request a location reference.  This is quick, but it only defers the cost of location determination.  A dereference needs to be performed by the call server.  A smart setup might have the LIS start determination at this point.

 [Option A - send location information]
 A3. The UE makes the INVITE, including location information.
 A4. The call server determines that the call needs routing and requests a route from the LoST server.

[Option B - determine route at the UE]
 B3. The UE requests a route using the location information from the LoST server.
 B4. The UE sends the INVITE, including the route information in the request.  This request should also include location information.

[End Options]
 5. The call server routes the call.

UE capabilities are exchanged with the LIS when requesting location information or the location reference.  The LIS is then able to exercise these capabilities as they meet the QoS needs (time, accuracy, precision).  This can be applied equally to UE requests; or requests from the call server.  I wrote a draft on this here:
  http://tools.ietf.org/html/draft-thomson-geopriv-held-capabilities

There are other aspects with the PIDF-LO extension that don't make sense.  For example, in many cases, the types of capabilities you indicate can be exchanged using the control or user plane signaling.  SUPL exchanges this information it its preliminary messaging; in GSM the classmark field indicates MS capabilities.

Cheers,
Martin

> Sent: Saturday, 22 July 2006 9:05 AM
> routing are supposed to work which seems to be mostly based on the NENA I2
> standard for fixed and nomadic users. If these were the only users, I
> still be useful). But for wireless users, what is being proposed will not
> work. If you refer to the latest 3GPP stage 2 definition for support of
> IMS emergency calls
> would attach here with highlighting if message size limits permitted) you
> will find substantiation of what I am saying.
> 
> the UE (handset) and visited network support enhanced cell ID positioning
> and A-GPS using SUPL 2.0 but not 3GPP control plane. The UE knows the
> serving cell ID when the call is placed but not its exact location. There
> is no time to perform accurate GPS (or A-GPS) positioning or request a
> position from the home network using SUPL and enhanced cell ID. The call
> (SIP INVITE) is sent to the visited network carrying the cell ID. The
> routing server (E-CSCF or LRF in the case of 3GPP) determines that 2
> different PSAPs serve different portions of the cell. The E-CSCF or LRF
> has the option of choosing a PSAP randomly (e.g. choose the PSAP serving
> the larger or more highly populated cell portion) or attempting to obtain
> a more accurate location. If the E-CSCF or LRF does not know the location
> solutions supported by the UE and the position methods, no intelligent
> decision can be made. If the E-CSCF/LRF attempts SUPL location it will, in
> this case, be able to obtain a location using enhanced cell ID positioning
> which could be very fast and (by narrowing down the portion of the cell in
> which the user is located) would enable a more reliable routing choice. If
> the UE did not support SUPL or enhanced cell ID positioning, time would be
> wasted in a fruitless positioning attempt and routing will not be
> improved. At some later time, the PSAP may request an accurate location
> estimate. In the 3GPP architecture, the request is sent to the LRF (or to
> the E-CSCF if that functions as the LRF). Knowing that the UE supports
> SUPL and A-GPS, the LRF can confidently instigate accurate positioning.
> Without that knowledge, the LRF could still make an attempt but would be
> forced to provide a phase 1 location estimate based on the original cell
> ID if the UE did not support SUPL. This is also the result if the LRF
> knows in advance that the UE does not support SUPL except that the
> response to the PSAP can be faster (e.g. allowing the PSAP extra time to
> query the user). Note that a location based on cell ID would not normally
> be sent to a PSTN capable PSAP together with call signaling because the
> (1). In this case, if the E-CSCF/LRF (or whatever will be defined in 3GPP2
> in place of these) knows the UE capabilities, it can avoid making a
> fruitless attempt to obtain a more accurate location for routing using
> enhanced cell ID. Without this knowledge, some implementations might waste
> time doing this (e.g. if most VoIP capable phones support SUPL 2.0). If
> the PSAP later requests an accurate location, the E-CSCF/LRF can avoid
> trying SUPL 2.0 which will just waste time. (Note that SUPL 2.0 allows a
> visited network to directory instigate positioning of a UE for an
> emergency call; with SUPL 1.0 only the home network can instigate
> the visited and home networks, the E-CSCF/LRF can still obtain a location
> by sending a request to the home network (actually to an H-SLP in the home
> network). This would be justified based on knowledge of support for SUPL
> 1.0 and A-GPS (e.g. it might not be justified if only enhanced cell ID was
> supported or if SUPL 1.0 was not supported).
> 
> --> SE: location references (e.g. to a LIS) will not generally be used in
> the 3GPP solution which is based on obtaining location through a real time
> location procedure involving the serving network and endpoint.
> 
> sufficient for wireless and has been effectively modified and enhanced in
> the 3GPP solution (and most likely same for 3GPP2 although that is still
> only defined at a stage 1 level)
> 
> (e.g. cell ID) maps unambiguously to a single PSAP and is accurate enough
> for the PSAP (without the need for re-positioning), then the additional
> information is not needed. That may often be the case for nomadic
> subscribers (whose location could be obtained from a wireline based access
> network and won't change subsequently) but it won't normally apply to
> wireless users where location won't typically be available from the access
> network (without executing some positioning procedure) and may change.
>

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 24 Jul 2006 09:45:20 -0400

Stephan

We had a meeting between the IETF and 3GPP emergency call folks in Montreal
just before the IETF meeting.  I thought that meeting went quite well, and
no one there seemed to think we needed the kinds of things you are
discussing.

I have reread 23.167, and except for noting the text "use of SUPL procedures
is dependent on UE capabilities", I see no references for a procedure
whereby the UE informs the P-CSCF, E-CSCF, LRF or RDF of its location
determination capabilities.  I further see no reference to a procedure where
any entity negotiates a location acquisition protocol with another.

Using your examples, in Example 1, the E-CSCF and the LRF are in the visited
domain.  They know if that domain supports SUPL or 3GPP control plane, and
don't need the UE to tell them.  They also know what location determination
mechanism the RAN supports; it's all one carrier's network.   I don't know
much about the allowed variability of what UEs have to support for location
determination, but I don't understand how you can build interoperable
systems if the RAN and the UE have freedom to implement multiple methods and
there is no requirement that one side implement all possible mechanisms.  I
don't understand how you can reasonable negotiate location determination
mechanisms.

I think that the UE capabilities always match the access networks
specifications, with no allowed variations, and thus an element in SIP
signaling between the UE and the P-CSCF or E-CSCF that includes UE location
determination capabilities is not only not needed, but can't work.  I
believe the same is true of the location acquisition protocol used within
the access network.

I does seem to me that 23.167 could be considerably simplified if the IETF
approach, including network assertion of location, was fully embraced.  The
number of variations in procedures could be considerably reduced, and the
text could be substantially simplified if it said, fairly uniformly, that if
the UE has location, it asserts it in the Location header, and if not, the
P-CSCF queries the (fill in the blank) for a reference to the location
information, and inserts it in a location header.  

Brian

> Sent: Friday, July 21, 2006 7:05 PM

---

From: "Edge, Stephen" <[email-masked]>
Date: Mon, 24 Jul 2006 18:32:33 -0700

Hi Martin

Thanks for the comments - although there was a further iteration of the discussion prior to your reply which has advanced the issues partly beyond this now.

The situation (somewhat simplistically) is that 2 alternative location solution sets appear to be conceded - the 3GPP and 3GPP2 set (comprising various control and user plane solutions) and one based on NENA and Ecrit concepts which I believe is less developed than the 3GPP/3GPP2 one (much of which has already been implemented and deployed).

Comments made in the context of one solution set don't always apply in the context of the other. For example, your following comment below seems to apply to NENA/Ecrit but not 3GPP/3GPP2 - "The UE decides that it doesn't have enough time to determine location.  (Note that this really isn't a valid decision.  Location information is necessary for emergency routing - you can't save time by avoiding this step.)". For 3GPP (3GPP2) location, anything that is UE initiated could take significantly longer. For example, the current serving cell would often unambiguously determine the PSAP, making any extra location a waste of time. The UE could only know that if interacted with a LoST server, but that is not part of the 3GPP solution. Or suppose that the UE supports SUPL and enhanced cell ID - then it could initiate SUPL location via its home network, but most likely the home network would need to involve the visited network, since enhanced cell ID requires local base station knowledge. This would end up as a more complex procedure (involving more signaling and network elements) than SUPL location using enhanced cell ID instigated by the visited network after the emergency call was initiated (allowable in SUPL 2.0 without involving the home network).

Here is another statement that appears context specific - "The trust relationship between the home network and the visited network is assumed. When you have to deal with a separation of access provider and voice provider these systems don't work". For emergency calls to a visited 3GPP or 3GPP2 IMS network, there generally will be a trust and roaming relationship with the access network (e.g. WLAN, HRPD RAN, HSDPA RAN) that will be sufficient to enable the call and authenticate the caller. 

And here is a third one although this seems to be aimed at 3GPP/3GPP2 - "For example, in many cases, the types of capabilities you indicate can be exchanged using the control or user plane signaling.  SUPL exchanges this information it its preliminary messaging; in GSM the classmark field indicates MS capabilities".  Control plane capabilities are transferred (from the UE) to the RAN, MSC and SGSN but no further (e.g. not to the E-CSCF or LRF). User plane capabilities are only transferred after a SUPL transaction has started - so the capability to support SUPL has to be known in some other way. (In addition, it might be nice to know the position methods supported before invoking SUPL because that might affect the decision to use SUPL.)

I believe the NENA/Ecrit model for location support needs more development before it can be assumed to provide a robust solution for both emergency calls and commercial services. For example, the existence or availability of a LIS server in every access network might be one issue. However, it is not my intention to compare this solution with the user and control plane solutions available to 3GPP and 3GPP2. What I am looking for is a resolution of the support for the 3GPP/3GPP2 location solutions which are all that are likely to be available to support wireless emergency calls.

Kind Regards

Stephen
-----Original Message-----
From: Thomson, Martin [mailto:[email-masked]] 
Sent: Sunday, July 23, 2006 5:50 PM
To: Edge, Stephen
Cc: Brian Rosen; [email-masked]
Subject: RE: [Geopriv] draft-hdesinen-geopriv-pidflo-extn-00.txt

Hi Stephen,

[End Options]

Cheers,
Martin

---

From: "Edge, Stephen" <[email-masked]>
Date: Mon, 24 Jul 2006 19:31:24 -0700

Hi Brian

Thanks for the comments. I was aware of the IETF-3GPP meting - which was organized by 3GPP CT1 who are not currently dealing with quite the same issues as 3GPP SA2 who define the architecture and stage 2 procedures. But you are right in one sense - this is not currently an issue in 3GPP, though that does not mean that it won't become one at some point.

You are also correct that 23.167 contains no requirement for the procedure we are proposing. This partly reflects the fact that 23.167 is entirely contribution driven and no one has yet proposed this. But it may also reflect the fact that such a capability cannot easily be included using 3GPP signaling capabilities alone - since any capability transfer probably has to use something related to SIP.

Your suggested resolution through supporting all location capabilities in all UEs and all networks is probably unworkable. For example, different world regions have different location requirements for emergency calls. The US is the most severe which explains why A-GPS and certain other network based methods like U-TDOA are deployed here. Europe by contrast has quite lax requirements explaining why most networks there support only cell ID based methods and have only recently started to trial and deploy GPS based solutions. I believe parts of Asia (e.g. Japan, Korea) are somewhere in between on this. On top of all this, the multiplicity of location solutions (SUPL 1.0 now, SUPL 2.0 in future, 3GPP control plane for UMTS, control plane for GSM and GPRS, different 3GPP2 user plane solutions) and location methods (A-GPS, OTDOA, A-FLT, enhanced cell ID, cell ID, U-TDOA) and in the future new satellite based methods like Galileo will almost certainly prevent universal implementation of everything in every UE and every network.

What this means is that knowing the UE location capabilities can be of considerable help in most effectively supporting emergency calls (at least in 3GPP and 3GPP2 wireless networks). Without that knowledge, various assumptions and guesses would have to be made which will sometimes degrade performance. 

Adopting the NENA/Ecrit location solution might seem to resolve all this, but as I have already remarked, there would be significant implementation impacts and it is not clear yet (without further elaboration of the solution) that it would necessarily always work for emergency calls and commercially.

So I believe we are left with the original problem that I stated and the question as to whether a Geopriv based solution or something else is the appropriate answer.

Kind Regards

Stephen
-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Monday, July 24, 2006 6:45 AM
To: Edge, Stephen; [email-masked]
Subject: RE: [Geopriv] draft-hdesinen-geopriv-pidflo-extn-00.txt

Stephan

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 25 Jul 2006 09:27:02 -0400

Stephan

You are on an IETF mailing list, specifically the geopriv mailing list,
asking the IETF to do some work.  In that context, I think you need to give
a lot more consideration to the IETF mechanisms in place, and developing
before asking the IETF to accept your premises.  You cannot say, in an IETF
context: "3GPP has decided to do things this way, therefore, you must
support our way of doing it in your protocol".  To my knowledge, the 3GPP
folks have never approached IETF in that way.  We seem to get more mileage
out of working more cooperatively, with more willingness to look at the
other point of view.

That doesn't mean I expect you to fully embrace what we have done so far.
Our work is limited by our collective experience, and bringing in new points
of view often changes the group's perception of what is needed.  I don't
think you will find geopriv to be hostile to new ideas, but you can't use
"we've decided to do it this way" on us.  I also don't believe that to be
the case.  I don't think 3GPP has decided these matters yet, as reflected in
its documents.

I'm still mystified about how you expect UE capability notification to be
useful to P-CSCFs and E-CSCFs.  I clearly understand the differences between
location determination requirements in various parts of the world.  I've
actually had discussions on this subject with EU regulators recently.
Although these differences clearly exist, and will exist for some time, I
think you will find that they will evolve over time to become more
homogeneous, but right now, the differences are there, and have to be dealt
with.  However, those differences, as you recite them, cannot explain the
utility of the function.  You will note that you have two major mechanisms
(route by cell site, and route by geo) and the latter has several mechanisms
to implement it (variations on handset based and network based).

All systems, including those in the U.S., need to be able to route on cell
site/sector.  I think you have mechanisms for sending that data already,
although in my personal opinion, we should be thinking about how exactly we
want to represent cell and sector in a PIDF.  I favor a polygon with proper
uncertainty, rather than the location of the cell and some code/value for
the sector.  In a PIDF, I don't think any kind of cell site code is
appropriate.

When the network, with or without handset participation, provides
geo-location capability, the network will implement ONE mechanism.  It's
just too expensive to implement more than one.  All of the handsets used on
that system will have to support that mechanism, to the extent handset
participation is required.  Handsets may indeed be built to participate in
more than one kind of system, but all handsets used in any visited network
must support whatever that network supports.  In that environment, knowing
what the handset supports isn't interesting at call time.  If it doesn't
support the location determination mechanism that network supports, it can't
be used on that network.  Such a determination would have to be made at
network attachment time, and not during an emergency call.  All elements
within that network know what it implements.  You don't need a PIDF to
transport that information.

If 3GPP expects any handset to be used on any network conforming to its
protocols, then it must have either the network implement all location
determination technologies it supports, or the handsets must.  You simply
can't allow both ends to choose and have interoperability.  If it doesn't
expect that level of interoperability (all handsets work on all networks),
then it needs some kind of network attachment negotiation mechanism that
allows the network and the handset to determine if they are compatible.  I
think that is beyond anything we deal with in geopriv.

With respect to protocol information, I think we're stuck pointing past one
another.  If you want SUPL to be considered for location acquisition (the
mechanism by which an endpoint learns its location), then it needs a geopriv
review.  I don't think you are proposing that.  Nor do you seem to be
proposing that SUPL or 3GPP control plane be used to convey location, as
does the SIP Location header/body, which would be between the UAC (a UE) or
proxy (a -CSCF) and the UAS or proxy, which also needs a geopriv review.
I've explained that in the IETF view, it's acceptable for a proxy (-CSCF) to
assert location on the SIP signaling.  How it gets that location is up to
it, and is within the domain of the visited network.  I don't understand why
the UE needs to know, and I really don't understand why the UE would be
telling any other element in the visited network what protocol the P- or E-
uses to get location before it puts it in a PIDF.  If actual location is
never getting put in a PIDF, then I'm really lost on why you need to put
this data in a PIDF.

Finally, you may not be aware of it, but NENA is embracing the IETF work,
and the Next Generation 9-1-1 system in the U.S. will expect to receive
emergency calls as SIP, with PIDF, routed by LoST.  Of course, that is
between, presumably, the E-CSCF and the PSAP (really, between the E-CSCF and
what NENA would call the Emergency Services IP Network).  I think what your
proposal deals with is before that.  

Brian 

> Sent: Monday, July 24, 2006 10:31 PM
> Thanks for the comments. I was aware of the IETF-3GPP meting - which was
> organized by 3GPP CT1 who are not currently dealing with quite the same
> issues as 3GPP SA2 who define the architecture and stage 2 procedures. But
> you are right in one sense - this is not currently an issue in 3GPP,
> though that does not mean that it won't become one at some point.
> 
> You are also correct that 23.167 contains no requirement for the procedure
> we are proposing. This partly reflects the fact that 23.167 is entirely
> contribution driven and no one has yet proposed this. But it may also
> reflect the fact that such a capability cannot easily be included using
> 3GPP signaling capabilities alone - since any capability transfer probably
> has to use something related to SIP.
> 
> Your suggested resolution through supporting all location capabilities in
> all UEs and all networks is probably unworkable. For example, different
> world regions have different location requirements for emergency calls.
> The US is the most severe which explains why A-GPS and certain other
> network based methods like U-TDOA are deployed here. Europe by contrast
> has quite lax requirements explaining why most networks there support only
> cell ID based methods and have only recently started to trial and deploy
> GPS based solutions. I believe parts of Asia (e.g. Japan, Korea) are
> somewhere in between on this. On top of all this, the multiplicity of
> location solutions (SUPL 1.0 now, SUPL 2.0 in future, 3GPP control plane
> for UMTS, control plane for GSM and GPRS, different 3GPP2 user plane
> solutions) and location methods (A-GPS, OTDOA, A-FLT, enhanced cell ID,
> cell ID, U-TDOA) and in the future new satellite based methods like
> Galileo will almost certainly prevent universal implementation of
> everything in every UE and every network.
> 
> What this means is that knowing the UE location capabilities can be of
> considerable help in most effectively supporting emergency calls (at least
> in 3GPP and 3GPP2 wireless networks). Without that knowledge, various
> assumptions and guesses would have to be made which will sometimes degrade
> performance.
> 
> Adopting the NENA/Ecrit location solution might seem to resolve all this,
> but as I have already remarked, there would be significant implementation
> impacts and it is not clear yet (without further elaboration of the
> solution) that it would necessarily always work for emergency calls and
> commercially.
> 
> So I believe we are left with the original problem that I stated and the
> question as to whether a Geopriv based solution or something else is the
> appropriate answer.
> 
> Kind Regards
> 
> Stephen
> I2
> you
> is
> > different.
> positioning
> 3GPP2
> waste
> thus
> > is
> URI
> arrive
> > at
> enough
> trying
> pidf-
> > lo
> > US
> due
> employ
> solution
> server
> alternative.

---

From: "Edge, Stephen" <[email-masked]>
Date: Tue, 25 Jul 2006 19:03:58 -0700

Hi Brian

Thanks for the comments. I can see I am probably never going to convince you. However, I hope at least to set the record straight on a number of inaccuracies and errors.

I am on the Geopriv list because we brought in a draft extension to pidf-lo principally to support location of emergency calls for the 3GPP and likely 3GPP2 solutions but also as a possible enhancement for other uses. By providing location capabilities in a pidf-lo it would be possible for locations servers who have no initial relationship with the endpoint to subsequently interact to obtain updated and more accurate location. I don't have any definite user cases to back this up (apart from emergency call support) but it is possible they may later exist if different location solutions continue to proliferate. I should also point out that the pidf-lo will most likely be used within 3GPP (and 3GPP2) - at least for IMS - and seems to be well on the way to becoming a worldwide accepted standard for conveying location related information, which means that restriction of usage and utility ought to be considered carefully.

Regarding the remarks on 3GPP (and 3GPP2) location solutions, these are a fact. They are there (period) and to hypothesize otherwise is simple hubris.

Your remarks on cell-sector routing are partly correct, except for overlooking the fact that cell boundaries and PSAP boundaries are commonly distinct which means that cell information alone may sometimes be inadequate. 

The following assumption is generally wrong - "the network will implement ONE mechanism.  It's just too expensive to implement more than one.  All of the handsets used on that system will have to support that mechanism, to the extent handset participation is required.  Handsets may indeed be built to participate in more than one kind of system, but all handsets used in any visited network must support whatever that network supports." Many 3GPP and 3GPP2 operators are already supporting control plane and user plane solutions - partly because, from a network perspective, there can be significant overlap. In addition, if SUPL is supported in a handset and home network, there need be no reliance, or just minimal reliance, on location support in the visited network. However, I agree that this does not apply to emergency calls, where the visited network and handset need to have some common location support. But it is far from clear that this means support of all alternatives by one side or the other - e.g. location is possible if both the handset and network support SUPL 1.0 but not SUPL 2.0 or if they both support 3GPP control plane but not SUPL. 

As regards "If you want SUPL to be considered for location acquisition (the
mechanism by which an endpoint learns its location), then it needs a geopriv
review", I believe you have gone off the deep end! SUPL has been developed within OMA (every bit as worldwide organization as IETF) and is being trialed for likely deployment by numerous operators. Why would a geopriv review be needed? 

As for your "Finally, you may not be aware of it" final paragraph, I am aware that NENA and Ecrit are collaborating on NG911 which seems to be no bad thing. But as you point out, that will mainly concern the interface to the PSAP and need not greatly affect how emergency calls and location are supported within the serving networks.

So perhaps I can summarize the main part of the discussion from my perspective by saying that in your view (as far as I can see - and please correct if wrong), 3GPP (and 3GPP2) should not have any real problem supporting location for emergency calls if they will only support location in certain ways (e.g. by converging on a single solution, by supporting all alternative solutions in the network or handset or preferably by embracing IETF defined solutions) but if they still do have a problem, then it is no issue for Geopriv.

I don't know if this reflects everyone's view (hopefully not), but I should congratulate you at least on building splendid silos!

Kind Regards

Stephen (final correction - that's how it's spelt)
-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, July 25, 2006 6:27 AM
To: Edge, Stephen; [email-masked]
Subject: RE: [Geopriv] draft-hdesinen-geopriv-pidflo-extn-00.txt

Stephan

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 26 Jul 2006 09:02:55 -0400

I'm going to take my discussion with Stephen (sorry for the typo) off line.
I'll summarize anything interesting I discover.  This exchange is not
heading in any good direction.

It might be useful (to him and I) if we heard from others on the list
whether they think they understand what is being proposed, and based on
their current level of understanding, whether they think there is something
there geopriv should work on.

For the record, I don’t understand it, and based on my limited
understanding, I don't THINK there is anything worth doing, but I have to
understand it better to really decide.

> Sent: Tuesday, July 25, 2006 10:04 PM
> Thanks for the comments. I can see I am probably never going to convince
> you. However, I hope at least to set the record straight on a number of
> inaccuracies and errors.
> 
> I am on the Geopriv list because we brought in a draft extension to pidf-
> lo principally to support location of emergency calls for the 3GPP and
> likely 3GPP2 solutions but also as a possible enhancement for other uses.
> By providing location capabilities in a pidf-lo it would be possible for
> locations servers who have no initial relationship with the endpoint to
> subsequently interact to obtain updated and more accurate location. I
> don't have any definite user cases to back this up (apart from emergency
> call support) but it is possible they may later exist if different
> location solutions continue to proliferate. I should also point out that
> the pidf-lo will most likely be used within 3GPP (and 3GPP2) - at least
> for IMS - and seems to be well on the way to becoming a worldwide accepted
> standard for conveying location related information, which means that
> restriction of usage and utility ought to be considered carefully.
> 
> Regarding the remarks on 3GPP (and 3GPP2) location solutions, these are a
> fact. They are there (period) and to hypothesize otherwise is simple
> hubris.
> 
> Your remarks on cell-sector routing are partly correct, except for
> overlooking the fact that cell boundaries and PSAP boundaries are commonly
> distinct which means that cell information alone may sometimes be
> inadequate.
> 
> The following assumption is generally wrong - "the network will implement
> ONE mechanism.  It's just too expensive to implement more than one.  All
> of the handsets used on that system will have to support that mechanism,
> to the extent handset participation is required.  Handsets may indeed be
> built to participate in more than one kind of system, but all handsets
> used in any visited network must support whatever that network supports."
> Many 3GPP and 3GPP2 operators are already supporting control plane and
> user plane solutions - partly because, from a network perspective, there
> can be significant overlap. In addition, if SUPL is supported in a handset
> and home network, there need be no reliance, or just minimal reliance, on
> location support in the visited network. However, I agree that this does
> not apply to emergency calls, where the visited network and handset need
> to have some common location support. But it is far from clear that this
> means support of all alternatives by one side or the other - e.g. location
> is possible if both the handset and network support SUPL 1.0 but not SUPL
> 2.0 or if they both support 3GPP control plane but not SUPL.
> 
> review", I believe you have gone off the deep end! SUPL has been developed
> within OMA (every bit as worldwide organization as IETF) and is being
> trialed for likely deployment by numerous operators. Why would a geopriv
> review be needed?
> 
> As for your "Finally, you may not be aware of it" final paragraph, I am
> aware that NENA and Ecrit are collaborating on NG911 which seems to be no
> bad thing. But as you point out, that will mainly concern the interface to
> the PSAP and need not greatly affect how emergency calls and location are
> supported within the serving networks.
> 
> So perhaps I can summarize the main part of the discussion from my
> perspective by saying that in your view (as far as I can see - and please
> correct if wrong), 3GPP (and 3GPP2) should not have any real problem
> supporting location for emergency calls if they will only support location
> in certain ways (e.g. by converging on a single solution, by supporting
> all alternative solutions in the network or handset or preferably by
> embracing IETF defined solutions) but if they still do have a problem,
> then it is no issue for Geopriv.
> 
> I don't know if this reflects everyone's view (hopefully not), but I
> should congratulate you at least on building splendid silos!
> 
> Kind Regards
> 
> > text could be substantially simplified if it said, fairly uniformly,
> that
> > if
> > > decision can be made. If the E-CSCF/LRF attempts SUPL location it
> will,
> > in
> > > which could be very fast and (by narrowing down the portion of the
> cell
> > in
> > > which the user is located) would enable a more reliable routing
> choice.
> > If
> > > the UE did not support SUPL or enhanced cell ID positioning, time
> would
> > be

---

From: Andrew Newton <[email-masked]>
Date: Wed, 26 Jul 2006 09:59:35 -0400

> heading in any good direction.

I agree and think this is a very good idea.

> understand it better to really decide.

I confess that I don't understand it either, but I'd also hate for us to 
miss something very important.  My limited understanding of the problem 
is that a small gap in our standard has been identified.

-andy

---

From: Randall Gellens <[email-masked]>
Date: Wed, 26 Jul 2006 08:52:39 -0700

>  the case.  I don't think 3GPP has decided these matters yet, as reflected in

The proposal, as I understand it, is for an optional extension to 
pidf-lo that will be useful in some specific cases.  It is not 
expected to be used or even supported in other environments.  If 
existing mechanisms will solve the problem Stephen has described, 
let's use them, but if not, an optional extensions seems reasonable.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
    The highlight of the annual Computer Bowl occurred when Bill Gates,
who was a judge, posed the following question to the contestants:
    "What contest, held via Usenet, is dedicated to examples of weird,
obscure, bizarre, and really bad programming?"
    After a moment of silence, Jean-Louis Gassee (ex-honcho at Apple)
hit his buzzer and answered "Windows."
                                          --Recounted by Adam C. Engst

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 26 Jul 2006 18:13:09 -0500

If this is the case and the use case is so restrictive, there is a
"namespace="##other" component in geopriv object for just this kind of
thing. Before running down that road though, I still feel very
unconvinced that a location reference won't do what is being asked here.