ecrit@ietf.org
[Top] [All Lists]

RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do endpointc

Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do endpointcentric LCPwithout giving away the store
From: "Brian Rosen"
Date: Mon, 16 Apr 2007 11:01:10 -0400
Okay, this is a "have your cake and eat it too" situation.

If you want to restrict location, you have to take on the burden of
providing the PSAP URI (the route) for an emergency call.  This would change
only when the user changed something like cell site.  You need to make sure
the endpoint has this when it changes.  You can either keep the update
frequency high, or force it when cell site changes (the endpoints know
this).

The IMS solution, because it couples the access network with the calling
network can avoid this because it uses proxy adding of location.  However,
the general packet interfaces have to support emergency calling too, and
here the L7 LCP would have to support the PSAP URI.

Brian

> -----Original Message-----
> From: Barclay, Deborah L (Deb) [mailto:dlbarclay@xxxxxxxxxxxxxxxxxx]
> Sent: Friday, April 13, 2007 12:08 PM
> To: Rosen, Brian; geopriv@xxxxxxxx
> Cc: ecrit@xxxxxxxx
> Subject: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do
> endpointcentric LCPwithout giving away the store
> 
> Hi Brian,
> 
> The ecrit bcp recommends obtaining location on power-up/registration and
> then refresh often/occasionally.
> 
> That means endpoints may obtain location frequently but never use it for
> an emergency call.
> 
> I thought business models often worked on a pay per dip basis.
> 
> For cellular endpoints, network based and network assisted position
> determination are very complex and resource intensive - requiring
> auxiliary equipment for position determination.
> 
> Due to the impact on network resources, I'm not sure obtaining position
> whenever requested and never being charged will be a viable model for
> some technologies.
> 
> Deb
> 
> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@xxxxxxxxxxx]
> Sent: Friday, April 13, 2007 6:18 AM
> To: geopriv@xxxxxxxx
> Cc: ecrit@xxxxxxxx
> Subject: [Ecrit] Not-so-grand compromise on how to do endpoint centric
> LCPwithout giving away the store
> 
> In the Emergency Services SDO Coordination workshop, a familiar
> discussion took place: how does location get provided for emergency
> calls?  The real issue is revenue.  Access networks have location.  They
> may be willing to (or may be regulated to be required to) provide
> location for emergency calls.  However, they are not willing to give it
> away for free for other uses.  The issue with that is how we support
> calling networks that don't have relationships with access networks,
> i.e. the Skype situation.  How is location provided such that a Skype
> emergency call can be placed, but the access network can restrict what
> else may be done with the location it provides?
> 
> We have been wrapped around the axle on this for, dare I say, years.
> 
> So, I think Barbara Stark first described this, and it needs some work,
> but suppose that, as an option, an access network could supply:
> 
> 1. A reference to location
> 
> 2. The results of a LoST query on the location value (viz, PSAP URI and
> local dialstring)
> 
> With this, an endpoint could recognize an emergency call and start
> routing it to the right PSAP.  The LIS would agree to dereference for
> PSAPs, but could restrict other uses of location.
> 
> Hannes points out that we need one more thing: the calling network has
> to be able to validate that the PSAP URI really is a PSAP URI so that
> charging (emergency calls generally are free) is protected.  We need a
> mechanism for them to do that.
> 
> Perhaps we include in the LoST return a country code for a query with a
> geo.  We add a new operation to LoST that takes a service, a country
> code and a PSAP URI and returns yes/no validation ("Yes, that URI is a
> valid URI for that service in that country").
> 
> What would we need to do to make this happen?
> 
> We need extensions to LCPs or some new protocol that returns an LbyR and
> the LoST results.  I wonder if this is just more HELD work.
> 
> We need the PSAP URI validation.
> 
> Again, this is optional.  The access network may well give up an LbyV.
> It may give up an LbyR that it will dereference for the endpoint.  The
> access network may have a relationship with the calling network such
> that the endpoint need not be involved.
> 
> The PSAP URI validation is actually useful without this idea, especially
> when location is an LbyR.  Instead of having to have the calling network
> dereference, and then do a LoST query to validate, it can just do this
> PSAP URI validation.
> 
> Would this solve our problem?  Would access carriers concerned about
> revenue issues with "giving away" location to it's subscribers be
> willing to provide LbyR dereferenceable by PSAPs (again remembering that
> the access network are local to the PSAPs) as well as LoST query
> services to their endpoints?  Would this address the concerns raised by
> Deutsche Telecom on this issue?
> 
> Let me be very clear that I think this is an ugly solution.  I think
> that everyone will be much better off if endpoints knew where they were,
> and apps could take advantage of that.  I think we'll get there.  I
> think tying location configuration with the LoST query is a bad idea.  I
> think using LbyR for emergency calls is a bad idea.
> 
> But I can live with it.
> 
> Brian
> 
> _______________________________________________
> Ecrit mailing list
> Ecrit@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ecrit
> 
> _______________________________________________
> Geopriv mailing list
> Geopriv@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/geopriv


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

<Prev in Thread] Current Thread [Next in Thread>