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
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
