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
