|
|
And IMS (and preceding cellular networks) actually calculate location at
the time of call initiation. Quality of Service indicators are used to
indicate that a low-delay response is required. This does not introduce
a significant delay to call setup - and it won't to VoIP calls either
(which, in my experience already typically have a longer setup time than
even cellular).
Location updates are used for more accurate location fixes - using a
delay-tolerant quality of service indicator. LbyR will be very useful
for this - particularly during the long interim period where the final
mile to the PSAPs will still be over conventional switched circuit
trunks (i.e. i2 architecture).
Working a BCP that initiates the location request at the time of
emergency call initiation would be a very good idea in my mind. Of
course, it requires the VoIP client to actually know it's doing an
emergency call - but I think that would be appropriate BCP as well.
Cheers,
Martin
-----Original Message-----
From: Brian Rosen [mailto:br@xxxxxxxxxxxxxx]
Sent: Tuesday, 17 April 2007 1:01 AM
To: 'Barclay, Deborah L (Deb)'; Rosen, Brian; geopriv@xxxxxxxx
Cc: ecrit@xxxxxxxx
Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to
doendpointcentric LCPwithout giving away the store
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
------------------------------------------------------------------------------------------------
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
Geopriv@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/geopriv
|
|