Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a LoSTQueryResponse

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Wed, 27 Sep 2006 18:13:56 +0200

Some of the terms like "anywhere" are very general. I am unclear whether you are giving a response based on NENA knowledge or a wider knowledge.

Remember the scope of ECRIT is to cover worldwide requirements, not just NAR. Can you rephrase you answer in terms of the geographical areas where you believe this is the answer, thus therefore identifying those regions where you do not have knowledge of the answer.

Regards

Keith 

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]] 
> Sent: 27 September 2006 12:42
> To: 'Edge, Stephen'; 'Henning Schulzrinne'
> Cc: 'ECRIT'; 'Thomson, Martin'
> Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a 
> LoSTQueryResponse
> 
> 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
> 
> > -----Original Message-----
> > From: Edge, Stephen [mailto:[email-masked]]
> > Sent: Wednesday, September 27, 2006 12:38 AM
> > To: Henning Schulzrinne
> > Cc: Brian Rosen; Thomson, Martin; ECRIT
> > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a LoST 
> > QueryResponse
> > 
> > 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,
> > 
> > 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:
> > 
> > > 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
> > >
> > > 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:
> > >
> > >> 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...
> > >>>
> > >>> 	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]
> > >>
> > >>
> > >> _______________________________________________
> > >> Ecrit mailing list
> > >> [email-masked]
> > >> https://www1.ietf.org/mailman/listinfo/ecrit
> > >
> 
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit
> 

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

---

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

Hi Brian, others

It's not clear if NENA are endorsing cell-sector routing or just simplifying how it should operate. If the former, I can't help commenting that cell-sector routing did not last very long for circuit mode since, soon after initially deployments and under pressure from the PSAPs, so called "interim positioning" was added to 3GPP and J-STD-036 spec.s. If IP based emergency call support goes the same way, the issue of performing more accurate positioning on a possibly selective basis (and at some cost in extra delay) will surely re-arise.

I also agree with Keith on the worldwide aspect - though up until now, NA seems to have monopolized the most stringent requirements.

Kind Regards

Stephen
-----Original Message-----
From: Drage, Keith (Keith) [mailto:[email-masked]] 
Sent: Wednesday, September 27, 2006 9:14 AM
To: Brian Rosen; Edge, Stephen; Henning Schulzrinne
Cc: ECRIT; Thomson, Martin
Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a LoSTQueryResponse

Regards

Keith

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 27 Sep 2006 19:46:24 -0400

The PSAPs would prefer to route on accurate data.  It can be a significant
problem to have the call routed incorrectly because the only information
known at the time the call was placed was cell/sector.

NENA's position is that, with current technology, cell/sector may be all the
information there is.  It's very clear they don't want to wait the 12-15
seconds to get accurate location before the call is routed.  Therefore, they
reluctantly accept routing by cell/sector.

Then you have the issue of, if you are routing by cell/sector, how you do
that.  Again, NENA has a pragmatic answer: they decide, in advance, which
PSAP should get the call for a given cell/sector, and they choose a point
within the cell/sector that represents the location of that cell/sector
which will route to the PSAP they want to get the call.  What I said above
isn't strictly true in that the chosen point doesn't actually have to be
within the cell/sector; it can be any point.

I asked them if they would prefer, or would be interested in, representing
the cell/sector as a shape, rather than a point.  Their answer (again, this
is North America, and really U.S.) was no, they wanted the representation to
be a point.  The carrier maps cell/sector to a point, and uses the point to
choose a route.

Summarizing, the preferred representation for the location of the CALLER is
a point.  The technology forces you to say "point with uncertainty".  If you
cannot, because of limitations in the technology, determine the point at the
time of the call, it is acceptable, if undesirable, to route based on the
cell/sector.  The preferred method for routing based on cell/sector,
according to this NENA group, is to map cell/sector to point, and then use
LoST to route based on that point.

Just as an aside, the PSAPs have a real problem with uncertainty, primarily
because there is no way to represent the information to a call taker when
different carriers use different uncertainty values.  Ask yourself what you
would like to see on a screen if you get one call with some location and 70%
uncertainty, and then immediately thereafter, get a call with the same
location and 50% uncertainty, how do you want the screen to show the
difference?  While uncertainty is a fact of life in the real world, the way
we deal with it today is not meeting the need.  The net result is that
uncertainty is ignored, not a good answer, but so far, I have not heard any
proposal for a better answer.  If all carriers used the same uncertainty
values, then we might have a way to represent the information.  If there was
an accurate conversion from one uncertainty value to another, that might be
useful, but I don't think any such thing exists.

Brian

> Sent: Wednesday, September 27, 2006 7:29 PM
> To: Drage, Keith (Keith); Brian Rosen; Henning Schulzrinne
> It's not clear if NENA are endorsing cell-sector routing or just
> simplifying how it should operate. If the former, I can't help commenting
> that cell-sector routing did not last very long for circuit mode since,
> soon after initially deployments and under pressure from the PSAPs, so
> called "interim positioning" was added to 3GPP and J-STD-036 spec.s. If IP
> based emergency call support goes the same way, the issue of performing
> more accurate positioning on a possibly selective basis (and at some cost
> in extra delay) will surely re-arise.
> 
> I also agree with Keith on the worldwide aspect - though up until now, NA
> seems to have monopolized the most stringent requirements.
> 
> Kind Regards
> 
> Stephen
> Some of the terms like "anywhere" are very general. I am unclear whether
> you are giving a response based on NENA knowledge or a wider knowledge.
> 
> Remember the scope of ECRIT is to cover worldwide requirements, not just
> NAR. Can you rephrase you answer in terms of the geographical areas where
> you believe this is the answer, thus therefore identifying those regions
> where you do not have knowledge of the answer.
> 
> Regards
> 
> Keith
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 27 Sep 2006 19:02:10 -0500

Brian,

TA/NMR and other similar technologies are provide second or subsecond location determination which provides significant improvements to accuracy over straight cell. Quite a few PDE and SMLC vendors have products in this space, and with the changes to J-STD-036 that Stephen mentions XY based routing deployments are occurring.

While I agree that cell-based may be all that is know, it is increasingly not the case, and there is no need to wait for 15 to 20 seconds to get a more accurate fix than cell-based for routing. I speak from experience here as we have products extensively deployed in this space.

Cheers
James

> Sent: Thursday, 28 September 2006 9:46 AM
> To: 'Edge, Stephen'; 'Drage, Keith (Keith)'; 'Henning Schulzrinne'
> Cc: 'ECRIT'; Thomson, Martin

------------------------------------------------------------------------------------------------
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: Wed, 27 Sep 2006 20:10:54 -0400

James

I know that.  PSAPs are very pleased with these developments.   We all look
forward to the day when no one has to route on cell/sector.  This points out
the fact that technology is evolving quickly, and we should expect the
requirements for location based services to move with the technology.

Brian

> From: Winterbottom, James [mailto:[email-masked]]
> Sent: Wednesday, September 27, 2006 8:02 PM
> To: Brian Rosen; Edge, Stephen; Drage, Keith (Keith); Henning Schulzrinne
> TA/NMR and other similar technologies are provide second or subsecond
> location determination which provides significant improvements to accuracy
> over straight cell. Quite a few PDE and SMLC vendors have products in this
> space, and with the changes to J-STD-036 that Stephen mentions XY based
> routing deployments are occurring.
> 
> While I agree that cell-based may be all that is know, it is increasingly
> not the case, and there is no need to wait for 15 to 20 seconds to get a
> more accurate fix than cell-based for routing. I speak from experience
> here as we have products extensively deployed in this space.
> 
> Cheers
> James
> 
> 
> > is North America, and really U.S.) was no, they wanted the
> representation
> > to
> > > called "interim positioning" was added to 3GPP and J-STD-036 spec.s.
> If
> > IP

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 27 Sep 2006 19:13:18 -0500

I guess all I am really trying to say is that I think that Stephen's proposal has merit.

> Sent: Thursday, 28 September 2006 10:11 AM
> To: Winterbottom, James; 'Edge, Stephen'; 'Drage, Keith (Keith)'; 'Henning
> Schulzrinne'
> > > NENA's position is that, with current technology, cell/sector may be
> all
> > > the
> > > seconds to get accurate location before the call is routed.
> Therefore,
> > > they
> > > be a point.  The carrier maps cell/sector to a point, and uses the
> point
> > > to
> > > choose a route.
> > >
> > > Summarizing, the preferred representation for the location of the
> CALLER
> > > is
> > > a point.  The technology forces you to say "point with uncertainty".
> If
> > > you
> > > cannot, because of limitations in the technology, determine the point
> at
> > > the
> > > different carriers use different uncertainty values.  Ask yourself
> what
> > > you
> > > would like to see on a screen if you get one call with some location
> and
> > > 70%
> > > difference?  While uncertainty is a fact of life in the real world,
> the
> > > way
> > > uncertainty is ignored, not a good answer, but so far, I have not
> heard
> > > any
> > > values, then we might have a way to represent the information.  If
> there
> > > was
> > > an accurate conversion from one uncertainty value to another, that
> might
> > > be
> > > > I also agree with Keith on the worldwide aspect - though up until
> now,
> > > NA
> LoST
> > > > > > >> server.  If we force the client to interpret inexactness,
> then
> > I
> > ------------------------------------------------------------------------
> --
> > ----------------------
> > ------------------------------------------------------------------------
> --
> > ----------------------
> > [mf2]
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 27 Sep 2006 20:18:40 -0400

I'll also re-iterate that average uncertainty is likely to be more 
misleading than helpful since there's likely to be bias for particular 
regions and points. In other words, a particular area may be 
particularly noisy (say, because of low signal levels), so that simply 
drawing the standard technology performance radius may well confuse more 
than help.

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 27 Sep 2006 20:15:52 -0500

I see that this entire discussion is fraught with assumptions, some of them misleading.

The reality of cell/sector, even if it does go away, is not something we should be concerned about.  We do not want, nor do we need, to consider primitives from the network bearer in our higher layer protocols.  LoST should deal only with location as input.

Currently, there is an optimization step that occurs where routing functions, which are co-hosted with determination functions, determine a route based on these network bearer primitives (SAI is the most widely used case).   This should not be relevant to our discussion because we have already drawn the line between the determination function and the routing function.

Just because we decide not to accept bearer primitives, doesn't mean that we should ignore the realities of the situation when considering the form of location that we handle.  The reality is that location is subject to uncertainty, and in mobile cases in particular, that uncertainty is more than we might otherwise like.  Yes, misrouting will occur, but obviously we need to take what steps we can to address that.  For the determination side, this is obviously about improving location precision; for the routing side, we obviously have a little way to go yet.

Cheers,
Martin

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 28 Sep 2006 09:04:08 -0400

Martin

I don't understand what this message is telling me.
I think there is no discussion on what is input, beyond the one issue I was
working on, which was whether there should be a representation of
cell/sector beyond what we now have.  The answer to that question, from
NENA's point of view, is no.

I think we all agree we have separated determination from routing.  I have
no idea what SAI is, but I suspect it's irrelevant to the present
discussion.

I don't know what a "bearer primitive" is, and I don't know if it has any
relevance to the present discussion.

I understand, in an engineering sense, what uncertainty represents.  I
accept that it represents "reality".  I am beginning to have a whole lot
more sympathy with the PSAP folks who are very frustrated with the engineers
and their uncertainty, mostly because no one can tell them what the heck
they can do with it.  What is it that anyone can do with uncertainty?  At
the moment, I have heard nothing beyond ignore it.  I understand that it's
real.  I have some vague notion that we should be able to use it
intelligently.  I have no idea what that is.

So, while I'm okay with carrying it around, in the hope that some day we can
use it, I'd rather not get into a lot of detail unless someone can say what
the heck we DO with it.  Right now, it's some number you can hide behind
when the caller isn't where he is reported to be ignoring uncertainty.
That's a useful thing in a legal sense, but doesn't really help anyone.

Brian

> Sent: Wednesday, September 27, 2006 9:16 PM
> To: Henning Schulzrinne; Brian Rosen
> Cc: ECRIT
> The reality of cell/sector, even if it does go away, is not something we
> should be concerned about.  We do not want, nor do we need, to consider
> primitives from the network bearer in our higher layer protocols.  LoST
> should deal only with location as input.
> 
> Currently, there is an optimization step that occurs where routing
> functions, which are co-hosted with determination functions, determine a
> route based on these network bearer primitives (SAI is the most widely
> used case).   This should not be relevant to our discussion because we
> have already drawn the line between the determination function and the
> routing function.
> 
> Just because we decide not to accept bearer primitives, doesn't mean that
> we should ignore the realities of the situation when considering the form
> of location that we handle.  The reality is that location is subject to
> uncertainty, and in mobile cases in particular, that uncertainty is more
> than we might otherwise like.  Yes, misrouting will occur, but obviously
> we need to take what steps we can to address that.  For the determination
> side, this is obviously about improving location precision; for the
> routing side, we obviously have a little way to go yet.
> 
> Cheers,
> Martin

---

From: "Edge, Stephen" <[email-masked]>
Date: Thu, 28 Sep 2006 19:55:26 -0700

Brian

I can't help commenting that uncertainty combined with a confidence
level (implicit or explicit) would be very helpful when looking for
someone or something because it tells you that area (or allows you to
calculate the area) that has to be searched. For example, a 911 call
from a large cell-sector where no more accurate location was available
or could be provided by the caller might have to be answered by more
than one emergency responder if time was critical. Conversely, if the
area was pinned down to a single block or a few buildings, one would
probably be enough. In general terms, search strategy can be dictated by
location plus uncertainty plus confidence (plus other factors like
environment, time of day, criticality etc.). If you have ever tried
looking for someone in an airport or shopping mall versus a specific
store or check-in area, you will know what I mean.

Kind Regards

Stephen
-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, September 28, 2006 6:04 AM
To: 'Thomson, Martin'; 'Henning Schulzrinne'
Cc: 'ECRIT'
Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a
LoSTQueryResponse

Martin

I think there is no discussion on what is input, beyond the one issue I

I think we all agree we have separated determination from routing.  I
have
no idea what SAI is, but I suspect it's irrelevant to the present
discussion.

I don't know what a "bearer primitive" is, and I don't know if it has
any
relevance to the present discussion.

I understand, in an engineering sense, what uncertainty represents.  I
accept that it represents "reality".  I am beginning to have a whole lot
more sympathy with the PSAP folks who are very frustrated with the
engineers
and their uncertainty, mostly because no one can tell them what the heck
they can do with it.  What is it that anyone can do with uncertainty?
At
the moment, I have heard nothing beyond ignore it.  I understand that
it's
real.  I have some vague notion that we should be able to use it
intelligently.  I have no idea what that is.

So, while I'm okay with carrying it around, in the hope that some day we
can
use it, I'd rather not get into a lot of detail unless someone can say
what
the heck we DO with it.  Right now, it's some number you can hide behind
when the caller isn't where he is reported to be ignoring uncertainty.
That's a useful thing in a legal sense, but doesn't really help anyone.

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 29 Sep 2006 07:48:18 -0400

Responders have experience looking for people who are not where they are
"supposed" to be.  What I am told is that the uncertainty/confidence
information cannot be correlated to anything resembling "actionable" (to
borrow a phrase) information different from a normal search mechanism,
especially when confidence is not expressed in consistent terms.

I come back to my original question.  Location is displayed on a screen for
a call taker.  They have a map.  It's easy to see how a point, or a hard
polygon, would be represented.  Tell me how you think a point with 50%
confidence should be represented vs the same point with 70% confidence,
using the same uncertainty shape.

Suppose you had a search team.  Tell me what you would tell that team which
would be different if the confidence factors were 10, 50, 70 or 90%, or if
the diameter of the uncertainty was 500m, 1km or 2km.  I kind of understand
that you might, if you could, vary the size of the team based on the size of
the uncertainty area, although I challenge you to make that into actionable
data if the confidence value varies.  My search and rescue friends tell me
that team size cannot realistically be significantly affected by this kind
of information, but is more a function of local practice, terrain, etc.

>From what they tell me, confidence/uncertainty information is NOT useful. 

Brian

> Sent: Thursday, September 28, 2006 10:55 PM
> To: Brian Rosen; Thomson, Martin; Henning Schulzrinne
> Cc: ECRIT

---

From: "Edge, Stephen" <[email-masked]>
Date: Fri, 29 Sep 2006 19:02:57 -0700

Hi Brian

Thanks for the comments. I appreciate that maybe uncertainty (and
confidence) are not considered very useful for searching, although if it
does or can affect the size of a search team, then it clearly has some
impact.

Neither of us are probably experts on conducting searches and it is
possible that an optimum search may have to proceed in the same manner
over each small area regardless of the size of the overall area (e.g.
start by searching the area with the highest probability, gradually
encompass areas with lower probability and continue until the target has
been found or the initially defined search area has been completely
searched). Knowing the most probable area at the start would allow you
to concentrate resources on this and reduce search time if the area was
reliable. So, for example, if the area included city blocks A to H but
not I to Z, I would tell my search team to focus on A to H and spend
less (or even no) time on I to Z until A to H had been searched. If I
had no area information at all and suspected that the location point
might not be accurate, I would be less inclined to ignore blocks I to Z.

I suppose the real issue is being able to present (e.g. on a map) an
area in which say a caller is expected to be with high probability (e.g.
95%) in a consistent manner. That is possible if the carrier provides to
the PSAP an area of uncertainty (e.g. circle, ellipse, sector, polygon)
together with a confidence level. For positioning methods that I am
aware of, confidence normally varies from around 39% (e.g. natural
result typical for an elliptical area) to 95% (e.g. delivered by some
location servers following internal manipulation). The uncertainty area
can be enlarged if confidence is less than the required level by making
assumptions regarding the location probability distribution - e.g. a
Gaussian distribution is often applicable in one dimension. For fairly
small areas (or maybe even larger ones), more pessimistic assumptions
could be used (meaning ones that would produce larger areas of
uncertainty). This would call for SW tools on the PSAP side (or the
transformation might be preformed in a GMLC or MPC). Ideally the
transformation would be performed in the terminal (for terminal based
positioning) or in the SMLC or PDE, but this will probably not be
feasible in the short term. The results would clearly have to be
evaluated through trials and/or through live experience.

This is not, of course, an instantaneously applicable solution and it
would most likely require cooperation and willingness within the
industry as a whole (carriers, vendors and PSAPs). But it seems better
than the rather adhoc situation now which has lead to results that are
somewhat low common denominators.

Kind Regards

Stephen
-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, September 29, 2006 4:48 AM
To: Edge, Stephen; 'Thomson, Martin'; 'Henning Schulzrinne'
Cc: 'ECRIT'
Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a
LoSTQueryResponse

I come back to my original question.  Location is displayed on a screen
for

Suppose you had a search team.  Tell me what you would tell that team
which
would be different if the confidence factors were 10, 50, 70 or 90%, or
if
the diameter of the uncertainty was 500m, 1km or 2km.  I kind of
understand
that you might, if you could, vary the size of the team based on the
size of
the uncertainty area, although I challenge you to make that into
actionable
data if the confidence value varies.  My search and rescue friends tell
me
that team size cannot realistically be significantly affected by this
kind
of information, but is more a function of local practice, terrain, etc.

Brian

> > I see that this entire discussion is fraught with assumptions, some
of
> > them misleading.
> >
> > The reality of cell/sector, even if it does go away, is not
something
> we
> > functions, which are co-hosted with determination functions,
determine
> a