Subject: [Ecrit] Indication of PSAP Confidence Level in a LoST Query Response

From: "Edge, Stephen" <[email-masked]>
Date: Mon, 25 Sep 2006 21:35:47 -0700

Hi All

Here is a topic that may or may not be new but maybe not yet presented
in this light. In the not so distant future and certainly within the
possible lifetime of the LoST capability, it may be possible using new
algorithms and additional processing and storage availability to
determine the probability that a particular PSAP URI is the correct one
for a provided geographic or civil location (taking account of the fact
that any provided location will often include, implicitly or explicitly,
some area of uncertainty). This capability is possible in principle even
today; it is just that the required amount of processing and storage may
be too high (or the ability of currently known algorithms too low) to
allow realistic and cost effective implementation.

Assuming that a probability value, AKA confidence level, was provided in
a LoST response, it would be possible with some solutions being
developed (e.g. 3GPP and maybe 3GPP2) to obtain a more exact location
for a wireless (or maybe wireline) user if the confidence value was not
high and no significant delay had yet been expended to obtain the
initial location. That would then allow a second LoST query with a
higher probability of success. It would also permit a network to
instigate the initial LoST query using simple location information such
as cell ID requiring no time to obtain. The overall result could be
significantly lower call delay wherever an initial location mapped
unambiguously to a single PSAP URI and more reliable routing for callers
in PSAP border areas.

This capability may seem strange in a wireline environment where a
terminal would typically stay put for extended periods of time allowing
plenty of opportunity to obtain a location before an emergency call was
originated. But in a wireless environment, it can be practically
impossible to know location with anything but very coarse accuracy at
any arbitrary point in time and the time needed to obtain a location
more accurately can be significant. It should also be noted that such an
enhancement to LoST could be mostly independent of the means used to
obtain location (whether for the first or second query). In other words,
such a capability need not (greatly) prejudice issues relating to the
architecture, procedures and methods used to obtain location.

Of course, such an enhancement to LoST might be added later after it was
well established that algorithms and computational capability would be
up to the task. But the addition of an extra optional parameter to a
LoST response need not impact implementations that choose not to use it
(either as a client or server). And later implementation support would
be easier because it would not require any new standards change. (Of
course, proprietary support would always be possible, but potentially
dangerous because of the risk of LoST evolution in some other direction,
such as provision of more than one PSAP URI.)

One possible consequence of this proposal might be to encourage
non-uniformity in the algorithms used to convert location to PSAP URI -
meaning different implementations could occasionally deliver different
URIs (and different confidence levels) for the same location input and
same PSAP database map. But I wonder if this should really be an issue -
e.g. it may well turn out that some algorithms are better (more
reliable, faster etc.) than others and that a demonstration of this in a
live environment would be a good way to ensure that the better ones
eventually become the ones most widely adopted.

Anyhow, please comment on this.

Kind Regards

Stephen
_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 26 Sep 2006 01:58:15 -0500

Hi Stephen,

I must admit, that I can’t see any tangible benefits for this right now – that is probably going to be the biggest point leveled against this proposal.

These sorts of discussion have been run in the past.  Consider the discussions on whether or not uncertainty should be included in LoST (check the archives; it was in the last few weeks).  And GEOPRIV have discussed confidence on the past, and aside from problems with people understanding the concepts, the main point against its inclusion was the lack of perceived benefit.

You are probably correct, in that we don’t know today how we could benefit from things like uncertainty and confidence in the future.  Certainly, there is wisdom in drawing a line and saying "Ware Ye, Here Be Dragons".  Even if you know that there are people living on the other side of that line happily, you can get on with your business, which is engineering workable solutions.

I suspect that this is primarily because people have trouble with the vagaries inherent in mobile and wireless systems.  For LoST, in the here and now, what you are asking for is a small change in the underlying philosophy.  This philosophy isn't necessarily written down, but you will find that this WG is currently operating under the assumption that its inputs will be simple.  This gives solid, repeatable results; you can write algorithms to that; and almost anyone can get it right.  Having one result is nice - we don't want request forking, which is a possibility unless you have a clear one-to-one mapping from location to URI...

	location -> FG -> FG (-> FG ...) -> Tree -> URI

You understand the vagaries, and are comfortable with them, but these scare the willies out of most people - because you don't get results in nice tidy boxes.  It's also harder to design a system that deals with fuzzy inputs.  To start with, you need a really compelling reason to do it.  Then, you need to make it so easy to do that not doing it would seem recalcitrant.

I personally like the idea of building in a little tolerance into the whole system.  And being able to convey this sort of information could be useful outside of an emergency situation as a sort of tuning mechanism.  Certainly, it would be useful in combination with location uncertainty and confidence to know whether or not current location information is adequate.

But this is from the person that reminded GEOPRIV that location isn't always a simple point in space.
 
Cheers,
Martin

________________________________________
From: Edge, Stephen [mailto:[email-masked]] 
Sent: Tuesday, 26 September 2006 2:36 PM
To: [email-masked]
Subject: [Ecrit] Indication of PSAP Confidence Level in a LoST Query Response

Hi All
Here is a topic that may or may not be new but maybe not yet presented in this light. In the not so distant future and certainly within the possible lifetime of the LoST capability, it may be possible using new algorithms and additional processing and storage availability to determine the probability that a particular PSAP URI is the correct one for a provided geographic or civil location (taking account of the fact that any provided location will often include, implicitly or explicitly, some area of uncertainty). This capability is possible in principle even today; it is just that the required amount of processing and storage may be too high (or the ability of currently known algorithms too low) to allow realistic and cost effective implementation.

Assuming that a probability value, AKA confidence level, was provided in a LoST response, it would be possible with some solutions being developed (e.g. 3GPP and maybe 3GPP2) to obtain a more exact location for a wireless (or maybe wireline) user if the confidence value was not high and no significant delay had yet been expended to obtain the initial location. That would then allow a second LoST query with a higher probability of success. It would also permit a network to instigate the initial LoST query using simple location information such as cell ID requiring no time to obtain. The overall result could be significantly lower call delay wherever an initial location mapped unambiguously to a single PSAP URI and more reliable routing for callers in PSAP border areas.

This capability may seem strange in a wireline environment where a terminal would typically stay put for extended periods of time allowing plenty of opportunity to obtain a location before an emergency call was originated. But in a wireless environment, it can be practically impossible to know location with anything but very coarse accuracy at any arbitrary point in time and the time needed to obtain a location more accurately can be significant. It should also be noted that such an enhancement to LoST could be mostly independent of the means used to obtain location (whether for the first or second query). In other words, such a capability need not (greatly) prejudice issues relating to the architecture, procedures and methods used to obtain location.

Of course, such an enhancement to LoST might be added later after it was well established that algorithms and computational capability would be up to the task. But the addition of an extra optional parameter to a LoST response need not impact implementations that choose not to use it (either as a client or server). And later implementation support would be easier because it would not require any new standards change. (Of course, proprietary support would always be possible, but potentially dangerous because of the risk of LoST evolution in some other direction, such as provision of more than one PSAP URI.)

One possible consequence of this proposal might be to encourage non-uniformity in the algorithms used to convert location to PSAP URI – meaning different implementations could occasionally deliver different URIs (and different confidence levels) for the same location input and same PSAP database map. But I wonder if this should really be an issue – e.g. it may well turn out that some algorithms are better (more reliable, faster etc.) than others and that a demonstration of this in a live environment would be a good way to ensure that the better ones eventually become the ones most widely adopted.

Anyhow, please comment on this.
Kind Regards
Stephen
------------------------------------------------------------------------------------------------
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]

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 26 Sep 2006 07:28:49 -0400

I'm not sure I understand what you are proposing.  The service boundaries
are hard edged polygons.  If you put a point in, you get an exact answer
out.  If you put a shape in, then we could have some kind of overlap of the
boundary polygons with the shape, and get uncertainty from that.  Is that
what you were proposing?

If so, I think I would support some kind of output that told you how close
of a fit we got.  If that's not it, perhaps you would explain in more detail
what you propose.

I do think we are pushing for the LoST resolver to be simple and
deterministic.  The reason is that it is not in a position to understand
what the tradeoffs are.  In general, the closer you get to the origin of the
location information, the more you understand what is actually happening on
the ground.  We want earlier elements to make the decisions, and not later
elements.  Thus we insist that if you have more than one location, the
client chooses, and not the server.  If we force the client to interpret
inexactness, then I think giving it as much information to make the choice
as we can is a useful thing to do.

Brian

> -----Original Message-----
> From: Thomson, Martin [mailto:[email-masked]]
> Sent: Tuesday, September 26, 2006 2:58 AM
> To: Edge, Stephen; [email-masked]
> Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a LoST
> QueryResponse
> 
> Hi Stephen,
> 
> I must admit, that I can't see any tangible benefits for this right now -
> that is probably going to be the biggest point leveled against this
> proposal.
> 
> These sorts of discussion have been run in the past.  Consider the
> discussions on whether or not uncertainty should be included in LoST
> (check the archives; it was in the last few weeks).  And GEOPRIV have
> discussed confidence on the past, and aside from problems with people
> understanding the concepts, the main point against its inclusion was the
> lack of perceived benefit.
> 
> You are probably correct, in that we don't know today how we could benefit
> from things like uncertainty and confidence in the future.  Certainly,
> there is wisdom in drawing a line and saying "Ware Ye, Here Be Dragons".
> Even if you know that there are people living on the other side of that
> line happily, you can get on with your business, which is engineering
> workable solutions.
> 
> I suspect that this is primarily because people have trouble with the
> vagaries inherent in mobile and wireless systems.  For LoST, in the here
> and now, what you are asking for is a small change in the underlying
> philosophy.  This philosophy isn't necessarily written down, but you will
> find that this WG is currently operating under the assumption that its
> inputs will be simple.  This gives solid, repeatable results; you can
> write algorithms to that; and almost anyone can get it right.  Having one
> result is nice - we don't want request forking, which is a possibility
> unless you have a clear one-to-one mapping from location to URI...
> 
> You understand the vagaries, and are comfortable with them, but these
> scare the willies out of most people - because you don't get results in
> nice tidy boxes.  It's also harder to design a system that deals with
> fuzzy inputs.  To start with, you need a really compelling reason to do
> it.  Then, you need to make it so easy to do that not doing it would seem
> recalcitrant.
> 
> I personally like the idea of building in a little tolerance into the
> whole system.  And being able to convey this sort of information could be
> useful outside of an emergency situation as a sort of tuning mechanism.
> Certainly, it would be useful in combination with location uncertainty and
> confidence to know whether or not current location information is
> adequate.
> 
> Here is a topic that may or may not be new but maybe not yet presented in
> this light. In the not so distant future and certainly within the possible
> lifetime of the LoST capability, it may be possible using new algorithms
> and additional processing and storage availability to determine the
> probability that a particular PSAP URI is the correct one for a provided
> geographic or civil location (taking account of the fact that any provided
> location will often include, implicitly or explicitly, some area of
> uncertainty). This capability is possible in principle even today; it is
> just that the required amount of processing and storage may be too high
> (or the ability of currently known algorithms too low) to allow realistic
> and cost effective implementation.
> 
> Assuming that a probability value, AKA confidence level, was provided in a
> LoST response, it would be possible with some solutions being developed
> (e.g. 3GPP and maybe 3GPP2) to obtain a more exact location for a wireless
> (or maybe wireline) user if the confidence value was not high and no
> significant delay had yet been expended to obtain the initial location.
> That would then allow a second LoST query with a higher probability of
> success. It would also permit a network to instigate the initial LoST
> query using simple location information such as cell ID requiring no time
> to obtain. The overall result could be significantly lower call delay
> wherever an initial location mapped unambiguously to a single PSAP URI and
> more reliable routing for callers in PSAP border areas.
> 
> impossible to know location with anything but very coarse accuracy at any
> arbitrary point in time and the time needed to obtain a location more
> accurately can be significant. It should also be noted that such an
> well established that algorithms and computational capability would be up
> to the task. But the addition of an extra optional parameter to a LoST
> response need not impact implementations that choose not to use it (either
> as a client or server). And later implementation support would be easier
> because it would not require any new standards change. (Of course,
> proprietary support would always be possible, but potentially dangerous
> because of the risk of LoST evolution in some other direction, such as
> provision of more than one PSAP URI.)
> 
> One possible consequence of this proposal might be to encourage non-
> uniformity in the algorithms used to convert location to PSAP URI -
> e.g. it may well turn out that some algorithms are better (more reliable,
> faster etc.) than others and that a demonstration of this in a live
> environment would be a good way to ensure that the better ones eventually
> become the ones most widely adopted.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 26 Sep 2006 08:26:20 -0400

I'll also add that earlier discussion has yielded the insight that  
sector-size areas are pretty useless for call routing, as there is a  
significant probability of mis-routes.

This probability won't be reduced all that much by fancy area  
maximization techniques or anything else since you simply can't tell  
which of the PSAP serving areas you're in. With area maximization,  
for example, users in a cell sector will simply be assigned to  
whatever PSAP service area dominates the cell sector. On average,  
across cell towers, that will still make it a 50/50 toss-up.

For dispatch, mid-sized areas of uncertainty are useful,  
corresponding to the typical FCC-compliant uncertainty regions of a  
few hundred feet. However, worrying that such areas span multiple  
PSAPs and then trying to pick the right one seems rather pointless  
(sorry...), given the complexity. (If clients really care, they can  
randomly sample the area, essentially doing a Monte-Carlo simulation,  
which will yield an area maximization by design.)

Thus, I just don't see the benefit. Either the area of uncertainty is  
too large for routing, as it is for tower/face information, or it is  
too small to worry about the right PSAP, and can be treated as a  
point for PSAP selection purposes.

Henning

On Sep 26, 2006, at 7:28 AM, Brian Rosen wrote:

>> reliable,
>> --------------------------------------------------------------------- 
>> -----
>> ----------------------
>> --------------------------------------------------------------------- 
>> -----
>> ----------------------
>> [mf2]
>
>

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 26 Sep 2006 18:30:53 -0400

Your proposal assumes knowledge of a probability distribution of the
target's location over the surface of the earth (or perhaps within a
volume over the surface of the earth. Is this reasonable, or capable of
approximation? I suspect it is possible only for certain access methods.

Edge, Stephen wrote:
> Hi All
> 
> Here is a topic that may or may not be new but maybe not yet
> presented in this light. In the not so distant future and certainly
> within the possible lifetime of the LoST capability, it may be
> possible using new algorithms and additional processing and storage
> availability to determine the probability that a particular PSAP URI
> is the correct one for a provided geographic or civil location
> (taking account of the fact that any provided location will often
> include, implicitly or explicitly, some area of uncertainty). This
> capability is possible in principle even today; it is just that the
> required amount of processing and storage may be too high (or the
> ability of currently known algorithms too low) to allow realistic and
> cost effective implementation.
> 
...

---

From: "Edge, Stephen" <[email-masked]>
Date: Tue, 26 Sep 2006 17:14:10 -0700

Hi Tom

Thanks for the comment. Your assumption is correct - and applies to all
positioning methods that I am aware of applicable to positioning of a
terminal accessing a cellular wireless network (e.g. it applies to cell
ID, enhanced cell ID, E-OTD, U-TDOA, A-FLT, OTDOA, GPS, A-GPS). 

Kind Regards

Stephen
-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]] 
Sent: Tuesday, September 26, 2006 3:31 PM
To: Edge, Stephen
Cc: [email-masked]
Subject: Re: [Ecrit] Indication of PSAP Confidence Level in a LoST Query
Response

...

---

From: "Edge, Stephen" <[email-masked]>
Date: Tue, 26 Sep 2006 18:28:52 -0700

Hi All

Thanks for the comments (Martin, Brian, Henning). Though not too
encouraging so far, here are a few responses.

Martin's comments: I am not proposing including confidence/probability
information in the LoST query (just a geographic shape would do)
although I believe it would help. My proposal is just to allow optional
addition of a confidence value associated with a single PSAP URI result
in the LoST response. That way the call server knows the likelihood of
misrouting (e.g. in some cases could be 50% or higher). If it turns out
that the chosen PSAP is not even E911 phase 2 capable, there could be a
major problem in rerouting to the correct PSAP because the initially
chosen PSAP will not be able to receive a more accurate location
estimate. However, I agree that this proposed capability may not be very
useful initially because servers may not support it and clients may not
be adaptable enough to take advantage. However, that could change in a
few years as algorithms get smarter. For example, it would probably be
quite simple to perform some of the calculations in non-real time - e.g.
associate each cell ID with a single PSAP URI and confidence level - and
perform a simple lookup in real time. If the capability is not allowed,
then it won't be possible (or at least not so straightforward) to
improve call setup time and routing reliability - which would be a pity.

Brian's comments: I agree that one input could be a hard edged polygon
in which case (if a uniform probability distribution is assumed), the
resulting confidence is just the proportional overlap with the PSAP
coverage area. For some positioning methods (e.g. yielding other
shapes), a probability distribution can be assumed in which case the
calculation of the confidence would be more complex (but still
possible). The LoST response can remain deterministic (assuming "perfect
algorithms") as long as the allowed geographic shape inputs are defined
carefully enough (e.g. state any default confidence level and/or
probability distribution). This is not to say that different algorithms
(or possibly even different implementations of the same algorithm) would
always yield the same results - in fact, due to approximations,
programming errors and shortcuts etc. they probably would not no matter
how simple you make the protocol definition (e.g. consider a point input
exactly on a PSAP boundary).

Henning's comments: you seem to be saying that cell-sector based
location estimates will typically cause routing errors whereas with more
accurate (E911 phase 2 type) location, any routing error (considering
that the terminal will be very close to the destination PSAP's coverage
area) will not be important. I have a somewhat different view though
based on similar premises. For a given geographic area location input L,
consider 2 possible results: (a) L is within one PSAP's coverage area
with a confidence level >=X (e.g. X = 90%); (b) L spans >=2 PSAP areas
with a confidence level <X in each. Assuming (a) occurs with significant
frequency when L is cell-sector based (which I would find hard to doubt
given the large numbers of small urban cells and some large PSAP
coverage areas), then using cell-sector as an initial input could be
sensible. For (b), there may be value in obtaining more accurate
location information because the smaller the size of L, the higher will
be the incidence of (a). (b) will still occur sometimes no matter how
small L becomes (unless a point), but then the argument that any
resulting routing error is less important comes to the rescue and you
end up with a methodology that can both reduce call delay and improve
routing reliability. (Note concerning Monte Carlo sampling by the
client: I agree that is one solution but rather inefficient, also
complex for the client.)

I look forward to more comments which hopefully can progress this.

Kind Regards

Stephen
-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Tuesday, September 26, 2006 5:26 AM
To: Brian Rosen
Cc: Edge, Stephen; ECRIT
Subject: Re: [Ecrit] Indication of PSAP Confidence Level in a LoST
QueryResponse

Henning

On Sep 26, 2006, at 7:28 AM, Brian Rosen wrote:

>> presented in

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 26 Sep 2006 21:51:49 -0400

Stephen,

any engineering is a trade-off between functionality and complexity.  
Speaking from some experience, I so far have always regretted when  
erring on the side of complexity, on the "it could be useful" theory.  
I have no intention of repeating this mistake for LoST, particularly  
for a truly mission-critical system.

You probably would want to review the list discussion as to why I  
believe any marginal increase in "correct" routing is just not worth  
the tremendous cost in overall system complexity and  
unpredictability. I won't bore the rest of the list by repeating these.

I just don't see cell sector as useful, long term, so whether it  
could actually work in some large number of cases is rather  
immaterial. Since we know that it will fail, regardless of  
probability routing or not, in an unacceptably large number of cases,  
it seems much better to design a system that actually works,  
particularly given that the technology is available and now standard  
on most modern cell phones. Old cell phone systems won't be running  
LoST anyway.

I have to admit that I find it rather uninteresting whether I call  
the wrong PSAP if I'm 100 ft from the border of the PSAP.  You'll  
always have cases where the initial route goes to PSAP A, but the  
caller moves to PSAP B while talking to the call taker. In the town I  
live, it probably takes about 2 minutes, at 30 mph, to cross the PSAP  
coverage area. Within that range, I'm also just as likely to report  
on an incident on the other side of the town border. Again, lots of  
complexity for no operational gain.

While it is theoretically possible, with some very low probability,  
to end up exactly on the border between two PSAPs, in that case, it  
just doesn't matter what happens and whether two implementations do  
the same thing. By definition, either PSAP is as good the other.

In those rare cases where the client cares, it can do the  
probabilistic computation. I'd rather have those that care, pay the  
cost, rather than everyone.

Henning

On Sep 26, 2006, at 9:28 PM, Edge, Stephen wrote:

>>> But this is from the person that reminded GEOPRIV that location  
>>> isn't
>>> always a simple point in space.
>>>
>>> Cheers,
>>> Martin
>>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 26 Sep 2006 22:05:49 -0400

> cost, rather than everyone.

This actually doesn't require Monte Carlo sampling, as I first  
surmised. The client only has to do the following:

(1) Get the centroid of the polygon. Get the mapping, which will  
return a PSAP and a service area.

(2) Compare the service region to the uncertainty region. If the  
service area covers more than 50% of the uncertainty region, you're  
done. This should be the most common case, as it is rather unlikely  
that the centroid is not in that area.

(3) If not, pick a point that is just outside the service area, and  
repeat (1).

Again, I don't recommend this, as the value is low, but it allows the  
client to do whatever fancy computation it wants, using all  
information at its disposal, including non-uniform probability maps,  
tarot cards and Ouija boards, without making the LoST infrastructure  
more complicated.

Henning

---

From: "Edge, Stephen" <[email-masked]>
Date: Tue, 26 Sep 2006 21:38:14 -0700

Hi Henning

Thanks for the further comments. I appreciate the points you are making.

For many wireless networks (e.g. 3GPP UMTS, cdma2000), a cell-sector ID
is all the network may generally receive from a terminal inside a SIP
INVITE - since any more accurate location may cost too much in time
(e.g. might not be associated by the network with an emergency call and
hence not assigned priority status). With the 3GPP current architecture
(3GPP2 has not yet decided one), this will be passed to an E-CSCF in the
serving network and thence to an LRF (Location Retrieval Function) for
use in deriving the PSAP URI. The LRF may be able to instigate more
accurate location (e.g. using a user plane location solution like SUPL
or using the 3GPP control plane solution) but this will take time and
resources. If it turns out that the cell-sector ID maps to a PSAP URI
with high confidence in a majority of cases, there would seem to be some
benefit in performing this mapping rather than adding extra delay by
attempting to obtain a more accurate location. Note that this is now an
issue of call delay just as much as routing reliability which may be
significant so long as legacy PSAPs have to be supported and there is
delay on both the packet and circuit mode sides as well as in providing
the interworking.

I should also point out that the proposed capability is generally not
possible for circuit mode wireless calls because the control points for
location and routing are separate. Using the same control point for both
functions allows an improvement (in terms of resource efficiency, call
delay and routing reliability) over circuit mode that could provide a
better service.

I agree that removing unnecessary complexity from the service and server
is worthwhile but I am not sure that an optional capability that can be
omitted initially should count very heavily. For example, it is possible
that algorithms that reliably deliver the most probable PSAP destination
(I mean the truly most probable one and not an approximation based on
centroids or other approximate data) will need the capability to compute
some confidence measure anyway as part of the selection process.

I suppose one conclusion of this discussion (given the direction in
which it seems headed) would be to leave out this capability initially
and then, based on actual call delay and routing results, reconsider it
or something similar later if needed.

Kind Regards

Stephen
-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Tuesday, September 26, 2006 6:52 PM
To: Edge, Stephen
Cc: Brian Rosen; Thomson, Martin; ECRIT
Subject: Re: [Ecrit] Indication of PSAP Confidence Level in a LoST
QueryResponse

Stephen,

Henning

On Sep 26, 2006, at 9:28 PM, Edge, Stephen wrote:

>>> --------------------------------------------------------------------

>>> -
>>> --------------------------------------------------------------------

>>> -

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 27 Sep 2006 07:42:07 -0400

A while ago, we had a discussion of whether there was a need to express cell
site and sector as an input format to LoST.  I took an action to ask NENA.
The "official" answer is not yet available, but unofficially, I can state
that there was no support for this idea anywhere.  

In fact, there was no support for representing cell site and sector by
anything except a point, which might be a civic or a geo.  The reality is
that the PSAPs and the wireless carriers get together and DECIDE which PSAP
gets calls from each cell site/sector.  Although there are frequent changes
in the tower arrangements, it seems there is a choice made who gets the
call.  Picking a point that lies within the desired PSAP boundary seems to
be a very acceptable mechanism.

Now, I think this is somewhat naïve, based on current experience, and may
need to be revisited as technology evolves.  However, we asked the question
of the experts, and that’s what they said they wanted.  In this case, we had
significant wireless carrier and PSAP participation in the discussion.

Although "quick fix" technology is getting better, and more prevalent, and
proliferation of location based services means more of the mechanism is
"turned on" all the time, most calls emergency calls are still routed by
cell site/sector.  More accurate information is obtained much later in the
call (15 seconds is a typical number).  Representing this location as a
point is the current answer, and I think that's all we should do now, even
though I personally think we will need more.

Brian

> Sent: Wednesday, September 27, 2006 12:38 AM
> To: Henning Schulzrinne

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 27 Sep 2006 09:07:14 -0400

> or something similar later if needed.

I agree with that general conclusion; nothing in the design of LoST  
prevents such an addition at a later time. As with any distributed  
system with many components operated by different jurisdictions,  
upgrading all components at the same time may well be difficult. One  
possible solution, which is roughly in the spec right now but needs  
some additional work, is to specify only a 3D-point as mandatory and  
allow the inclusion of another "fancy" (some 3D) location object that  
servers are free to ignore. That way, "old" or "simple" systems will  
do roughly the right thing, without preventing advanced implementations.

You don't want to get the situation that the first resolver doesn't  
understand the new location object, and thus can't pass the request  
to others (or, maybe worse, that some LoST server in the middle of a  
referral chain chokes on the format).

Henning

---

From: "Edge, Stephen" <[email-masked]>
Date: Wed, 27 Sep 2006 16:35:00 -0700

Thanks for the answer. So for the time being, we drop the issue. I
assume that forward compatibility (e.g. inclusion of optional
unrecognized parameters in both a query and response) will be supported
in the first version to ensure that such enhancements remain possible.

Kind Regards

Stephen
-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Wednesday, September 27, 2006 6:07 AM
To: Edge, Stephen
Cc: ECRIT
Subject: Re: [Ecrit] Indication of PSAP Confidence Level in a LoST
QueryResponse

Henning