I think your document doesn't address the particular use case. Or maybe
it does - and I need to spend more than two minutes reading it.
I think there are assumptions that a) the LIS actually knows the
location with sufficient accuracy to unambiguously select the right
routing boundary and b) the LIS has access to all the relevant routing
boundaries in an a priori fashion.
In the use case under discussion, the LIS is providing an initial coarse
location fix - e.g. it does a cell/timing measurement and gets, say, a
1500m radius of uncertainty. No time to integrate multiple uplink timing
measurements, no time to indulge in AGPS procedures.
Given that area of uncertainty could encompass an arbitrary number of
routing area boundaries - particularly if you include the "holes" in
routing boundaries consideration, there is no practical way to identify
every possible routing region from LoST queries without, for example,
iterating through a grid of points encompassed by the area of
uncertainy.
In any case, this is just a back door way to provision LoST into the
LIS. There are much more optimal ways to do that than using the actual
LoST protocol.
It's no good dismissing this as an optional optimization. Of course it
is. However, the proposition in the NENA discussion was that LoST
queries only ever get done using a point argument. This forces the
situation where the LIS is the only place that can do the optimization.
This in turn begs the question of what value, beyond making the
emergency call initiation more complex than it has to be, the LoST
interaction adds. If LoST stays in the picture and its role is routing,
and it is, then it should be the node that retains the optimization
option.
Cheers,
Martin
-----Original Message-----
From: Richard Barnes [mailto:rbarnes@bbn.com]
Sent: Wednesday, 3 June 2009 1:09 PM
To: Dawson, Martin
Cc: Rosen, Brian; geopriv@ietf.org
Subject: Re: [Geopriv] HELD ResponseTime parameter with value
emergencyRouting
Martin,
It actually isn't that onerous for the LIS to check whether a given
location is 'good enough for routing'. Basically, it involves a lot of
LoST queries to collect service boundaries for the relevant areas, some
off-line computations, then only a polygon-in-polygon check at query
time. We describe an algorithm in draft-barnes-ecrit-rough-loc:
<http://tools.ietf.org/html/draft-barnes-ecrit-rough-loc#section-3>
Picking a service region (as I think your quote from Brian suggests a
LIS would do) is then just a matter of intersecting the two polygons.
That said, it seems to me that whether the LIS applies such an algorithm
is still a matter of local policy, with no protocol changes necessary.
--Richard
Dawson, Martin wrote:
> The NENA discussion hinged around the question of whether the routing
> service (LoST) should apply weighted routing to the location offered
by
> the device - and let's assume the relevant use case is that the
network
> LIS provided this location in, say, a cellular network. Proponents of
> weighted routing pointed out that the uncertainty around a cell may
> overlap two or more routing boundaries and that the optimal approach
is
> to determine which routing area the largest proportion (weight) of the
> uncertainy falls into.
>
> Those opposed to this approach said that, in fact, the location should
> just be provided as point - ignoring the fact that uncertainty is
> associated with it. And this proposal was made on the basis that *the
> LIS should ensure that the point provided falls into the correct
> (optimal?) routing area before providing it to the client*
>
> This sentiment is reflected in the following from Brian's post on this
> thread:
>
>> I claim that it is perfectly reasonable to expect the LIS to
construct
> a
>> PIDF suitable for the purpose of emergency routing when it encounters
> the
>> emergencyRouting value in responseTime
>
> The real kicker in this is that the LIS *has to perform actual routing
> analysis before providing the location*. The inevitable consequence of
> this is that the LIS has to have some sort of access to the routing
> boundary information in order to do this - don't forget a cellular
> location can't be stored in the LIS before hand; it's generated
> dynamically. So now, the LoST data, including multiple adjacent
boundary
> information, also has to live in the LIS or be otherwise accessible to
> it.
>
> Now - if this is a reasonable expectation, and I'm not saying it
isn't,
> then it must raise the question of why use LoST at all to do the PSAP
> URI lookup, why not have the LIS deliver it directly since it's
already
> had to perform routing? I don't buy an interoperability argument
against
> this. An optional extension in the HELD response could contain the
PSAP
> URI. Any device not supporting it can fall back to looking for LoST.
It
> means that broadband providers could start providing ECRIT emergency
> call routing without the public LoST deployment/management problem
> having to be solved. Public network operators already do this routing
> analysis for the PSTN including cellular; it's not a new ask.
>
> Cheers,
> Martin
>
>
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Rosen, Brian
> Sent: Wednesday, 3 June 2009 10:42 AM
> To: geopriv@ietf.org
> Subject: [Geopriv] HELD ResponseTime parameter with value
> emergencyRouting
>
> In NENA, there is a discussion on the best form (shape) to send to the
> LoST server when the shape is a cell sector. The discussion itself is
> pretty specific to NENA, although it involves the fact that it might
be
> necessary for the LIS to choose the shape of the response for
emergency
> routing that might be different than it would return for other
purposes.
>
>
> Martin Thompson is worried about something that I seek advice on.
>
> The wording choice for ResponseTime in HELD is:
> 6.1. "responseTime" Parameter
>
> The "responseTime" attribute MAY be included in a location request
> message. The "responseTime" attribute includes a time value
> indicating to the LIS how long the Device is prepared to wait for a
> response or a purpose for which the Device needs the location.
>
> In the case of emergency services, the purpose of obtaining the LI
> could be either for routing a call to the appropriate PSAP or
> indicating the location to which responders should be dispatched.
> The values defined for the purpose, "emergencyRouting" and
> "emergencyDispatch", will likely be governed by jurisdictional
> policies, and should be configurable on the LIS.
>
> Please note the construction of the last sentence of the first
paragraph
> about "purpose".
>
> I claim that it is perfectly reasonable to expect the LIS to construct
a
> PIDF suitable for the purpose of emergency routing when it encounters
> the emergencyRouting value in responseTime, and the fact that it is in
> the "responseTime" parameter doesn't limit the LIS from sending an
> appropriate PIDF content as well as within an appropriate time limit.
> The LIS knows the purpose, and can reasonably be expected to respond
> appropriately in both time and content. Otherwise, we would need
> another parameter to ask for the right content, which is silly.
>
> I have been okay with the current wording because I believed that the
> LIS could use the emergencyRouting (or emergencyDispatch for that
> matter) as an all purpose "purpose" (as it were) and wasn't hung up on
> the fact that it's in the responseTime parameter.
>
> Am I wrong?
>
> Brian
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.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@ietf.org
> https://www.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@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
