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

["Thomson, Martin" <[e-mail]>]

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

> -----Original Message-----
> From: Edge, Stephen [mailto:[e-mail]]
> Sent: Saturday, 22 July 2006 9:05 AM
> To: Brian Rosen; [e-mail]
> Subject: RE: [Geopriv] draft-hdesinen-geopriv-pidflo-extn-00.txt
> 
> 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:[e-mail]]
> Sent: Friday, July 21, 2006 7:29 AM
> To: Edge, Stephen; [e-mail]
> 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.
> 
> --> SE: this is not part of the 3GPP solution
> 
> 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)
> 
> At no time did any element need to know if A-GPS or A-FLT were possible
> choices.
> 
> --> 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.
> 
> So, I'm back to not understanding what the draft does that we haven't
> already dealt with.
> 
> Brian
> 
> 
> 
> ________________________________________
> From: Edge, Stephen [mailto:[e-mail]]
> Sent: Friday, July 21, 2006 2:29 AM
> To: Brian Rosen; [e-mail]
> 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:
> <[e-mail]>
> *       List-help: <mailto:[e-mail]?subject=help>
> *       List-id: Geographic Location/Privacy <geopriv.ietf.org>
> *       List-post: <mailto:[e-mail]>
> *       List-subscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>,
> <mailto:[e-mail]?subject=subscribe>
> *       List-unsubscribe:
> <https://www1.ietf.org/mailman/listinfo/geopriv>,
> <mailto:[e-mail]?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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

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