Subject: RE: [Ecrit] Issue 35: Location Validation - Geodetic

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 19 Apr 2006 19:05:08 -0500

I don't think that this is a real problem.  Geodetic information would be evaluated against a set of PSAP boundary polygons, not converted to civic, as you seem to imply (my reading).  Presumably there would be no black spots not covered by PSAPs, except perhaps in international waters (and I'm happy to leave that one for now).  A request for a route occurs at an instant in time, with the information that is available at that time, irrespective of it's accuracy.
 
There is no real concept of validation in Phase-II E-911.  Currently, each serving cell is mapped to a PSAP and the switch routes the call to the SR based on the serving cell identifier.  That is, routes are statically configured.  If J-STD 36-B with it's X-Y routing functionality were more widely deployed, then a coarse estimate would be used (almost as coarse as cell in effect) against the PSAP boundaries, which are represented as polygonal areas.
 
The point being that geodetic infomation is rarely, if ever going to produce a no-route result.  That problem is one for civic addresses.  Civic validation may also be a problem only in certain countries; for routing, Australia would be fine with one civic field only, which would make our validation database very easy to implement.
 
Cheers,
Martin
 
p.s.Note that PSAP boundaries for wireline and cellular can differ slightly because of this.  It's possible to reach different PSAPs from a landline and mobile phone right next to each other.  And yes, misrouting is very common, X-Y is supposed to help with that...a little.

________________________________

From: James M. Polk [mailto:[email-masked]]
Sent: Thu 4/20/2006 8:23 AM
To: [email-masked]; Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [Ecrit] Issue 35: Location Validation

I agree with almost everything Brian says (surprise!), especially about how
to work out additional info if a match isn't made.

I'm weary about how to pull this off for geo though, due to the rigidity of
what doesn't constitute a match.  Given that GPS accuracy is roughly within
15 ft after a few minutes and within a few feet after a bit longer (you get
the idea of increasing accuracry with time), with some reports where they
are might fall *just* outside of a valid location match, and return an
error.  This might just occur for someone in the middle of the street, say
at a car accident or a hurt child next to their bike, and no one wants this
not getting through to a PSAP.

Geo almost should have a match to some PSAP if the caller is within a
jurisdiction (say a country or state or province or county), and not only
when they are at a street address that's nice and neat like civic
addresses, but this is an interesting problem we haven't really gotten into
to solve for yet, have we.

How does the Phase-II cellular world solve this validation question when
presented with GPS coordinates to a wreck down a canyon road that has no
(housing) lot addresses?

If this isn't solved for in an agreed upon way, this almost begs for a "Geo
Considerations" ID to have a specific discussion about.

At 05:02 PM 4/19/2006 -0500, [email-masked] wrote:
>In North America, validation is a well known, and required step in
>processing a civic location.  In the current system, there is no
>validation of geo.
>
>In the end, validation in the current system means:
>    Do we know where this location is; can we send someone to help
>    by giving him this location?
>
>To do that, there is presently a database, called the Master Street
>Address Guide, which contains a list of all the "known" street addresses.
>Validation, today, means that before a location is put into the database
>that is actually used to determine address when an emergency call is made
>(the "ALI" database), the location is looked up in the MSAG.  If there is
>a match, the update to the ALI is permitted.  If there is no match, the
>update is not allowed and the carrier attempting to update the ALI has to
>go figure out what happened.
>
>The MSAG database sometimes also is aligned with the database used to
>dispatch responders.  A location submitted to the responder Computer Aided
>Dispatch system must be "MSAG Valid".
>
>The emergency call system in North America is heavily dependent on
>validation; many attempts at coming up with a location don't yield
>something unique enough to use for locating where someone is unambiguously
>so that help can be dispatched correctly to where they are when they can't
>answer questions.  This is a firm requirement for us, and we really,
>really need to have it.
>
>The current MSAG would be the natural beginning source of the mapping
>database envisioned by ecrit.  There are a whole host of formatting and
>correlation issues.
>
>It is essential that validation happen BEFORE an emergency call.  Ideally,
>it would happen when it happens now; when a location is put into the
>database that stores location (the Location Server).
>
>Given the current design of the ecrit mechanisms, and accepted
>requirements, the minimal way to do validation is to allow a mapping any
>time (like when the location is put into the Location Server), and return
>some kind of error when the location presented is not in the database.  So
>validation means "I have no mapping for that location".
>
>A better answer would be to have a mechanism in LoST specifically for
>validation that could return more information than just "I have no
>mapping".  For example, it would be helpful to return possible alternative
>valid mappings.  A typical example is you query for "100 Main St" and the
>mapping server returns "I don't have a 100 Main St, but I have a 100 N
>Main St or 100 S Main St".  You could also return an indication of which
>elements in the input location were valid (Country, State, and City was
>valid, but Street Name was not).  It would also be useful to return
>information not included in the original request (for example, you query
>with the postal community name, but leave off county and jurisdictional
>community name, if a unique mapping was found, the missing data was
>supplied).
>
>It would also be good to have a form of validation for geo, which amounts
>to "there are no URIs for the service you requested with the <geo>
>location you provided".  If you ask for police while you are in the middle
>of the Atlantic Ocean, you might get that response.
>
>
>Brian
> > Hi all,
> >
> > we need to close issue#35 about location validation. The issue can be
> > found at: http://www.ietf-ecrit.org:8080/ecrit-req/issue35.
> >
> > Note that I provide a summary at the end of my mail.
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-06.txt
> > says:
> >
> > "
> >     Location validation: A caller location is considered valid if the
> >        civic or geographic location is recognizable within an acceptable
> >        location reference systems (e.g., USPS, WGS-84, etc.), and can be
> >        mapped to one or more PSAPs.  While it is desirable to determine
> >        that a location exists, validation may not ensure that such a
> >        location exists.  Location validation ensures that a location is
> >        able to be referenced for mapping, but makes no assumption about
> >        the association between the caller and the caller's location.
> > "
> >
> > We had a discussion about this subject during the interim meeting:
> > http://www.ietf-ecrit.org/Interim2006/Jabber-Log_2006-02-01.html
> >
> > ----------------
> >
> > [07:53:24] <anewton> roger: issue 15 re validation of civic
> > [07:53:39] <anewton> andy: I thought the list left the issue not about
> > not doing it, but how.
> > [07:53:46] <anewton> roger: need to know about the language in the draft
> > [07:54:08] <anewton> brian: something about a way to do it
> > [07:54:24] <anewton> jon: related to other req. such as querying it
> > anywhere.
> > [07:54:37] <anewton> james p.: we are no validating
> > [07:54:56] <anewton> ted: text in the issue tracker is not the meaning
> > of validation in NENA, etc...
> > [07:55:12] <anewton> ted: this is a valuable piece of protocol machinery.
> > [07:55:39] <anewton> james: that makes sense, but the text doesn't say
> > that
> > [07:56:03] <anewton> brian: if validation is defined as succesful
> > mapping to the PSAP, then that is what we want.
> > [07:56:11] <anewton> james: need other word than "valid"
> > [07:56:28] <anewton> brian: what we have can be used for NENA view of
> > the world
> > [07:57:01] <anewton> james: anything out of this building to the proper
> > PSAP, but not floor by floor
> > [07:57:16] <anewton> brian: the requirement is to know that you can send
> > a responder.
> > [07:57:32] <anewton> marc: not sure that is the NENA view, re ESN
> > [07:58:04] <anewton> brian: the location is knowing we can send a
> > responder
> > [07:58:09] <anewton> nadine: agree
> > [07:58:52] <anewton> brian: definition of valdiation to be successful
> > mapping to occur for the location
> > [07:59:10] <anewton> ted: this requirement needs the point brian is making
> > [07:59:49] <anewton> james: concerned with people thinking we mean
> > something much more precise
> > [08:00:12] <anewton> hannes: the definition does not match the requirmenet
> > [08:00:26] <anewton> roger: let's examine the definition first
> > [08:01:09] <anewton> nadine & brian: this is a good defintion
> > [08:01:15] <anewton> james: no, that is cumbersome
> > [08:03:04] <anewton> henning: problem is that this is trying to define
> > validation for both civic and geo. first test is syntactic validity. the
> > description is not clear if the actual address exists.
> > [08:03:49] <anewton> henning: second test, is there a valid mapping,
> > third, is there a street address that can be routed to.
> > [08:04:14] <anewton> brian: clarifying this is a good idea.
> > [08:04:21] <anewton> nadine: agree with 1 and 2, but not 3
> > [08:04:27] <anewton> roger: we cannot achieve 3
> > [08:04:38] <anewton> henning: then we need to be clear about it
> > [08:05:36] <anewton> roger: "but not equivicate to an address" ?
> > [08:05:58] <anewton> brian: add new sentence to clarify it. "while
> > desirable to have the address exist, not guarnateed."
> > [08:06:46] <anewton> ted: wandering from the protocol requirement. an
> > address could be invalid for other purposes but could get mapped to a
> > PSAP.
> > [08:07:46] <anewton> ted: could I give you a PSAP based on the location
> > given, if answer is yes then that is the one thing we care about
> > [08:08:01] <anewton> henning: just need a qualification of what it does
> > not mean
> > [08:08:42] <anewton> brian: agree, see my previous wording
> > [08:09:17] <anewton> marc: mentions some use case in Texas.
> > [08:09:25] <anewton> brian: but that is not how it will work
> > [08:09:40] <anewton> marc: but if the address does not exist, no PSAP
> > [08:09:46] <anewton> brian: that is making an assumption
> > [08:10:35] <anewton> brian: current MSAG does address ranges, but we
> > should have ability in future to work on single addresses
> > [08:11:07] <anewton> marc: do you believe it shouldn't return an answer?
> > [08:11:10] <anewton> brian: ?
> > [08:11:41] <anewton> ted: in some administrations, the answer will be
> > "here is your PSAP, and btw the address you gave is foobar"
> > [08:13:18] <anewton> nadine: be able to distinguish if it is the "right"
> > PSAP vs "default" PSAP?
> > [08:13:47] <anewton> ted: for validation it would be "right".
> > [08:14:33] <anewton> henning: this has implication on protocol design
> > choices.
> > [08:15:57] <anewton> henning: difference in use case in validation and
> > non-validation (emergency case) and the bits on the wire in the protocol
> > [08:16:00] <anabolism> If the case is that the address is 125 main
> > street, and 124 and 126 exist but 125 does not, would validation
> > indicate that the address is syntactically valid, the psap returned
> > would be for 124 and/or 126?
> > [08:17:19] <anewton> are you asking a question for the room?
> > [08:17:36] <anabolism> yes, but we've moved on abit
> > [08:18:06] <anabolism> I was trying to clarify comments from several
> > people
> > [08:19:21] <anewton> brian: answering randy's q: "I can map it, but it
> > isn't really valid. But in an emergency, it would send you to the
> > closest PSAP."
> > [08:19:32] <anabolism> Thanks, sounds reasonable to me
> > [08:19:46] <anewton> marc: result should be saying there is a problem in
> > XML
> > [08:19:51] <anewton> brian: yes
> > [08:20:12] <anewton> brian: it is desirable to say you can get a
> > mapping, but there is a problem with the address.
> > [08:21:20] <anewton> henning: even in a real emergency query, this is
> > nothing wrong with indicating that the address is foobar as long as the
> > PSAP is returned
> > [08:22:11] <anewton> ted: in a real emergency only look at the one thing
> > they map on. validation may be a different task.
> > [08:22:47] <anewton> brian: but that work for you
> > [08:22:56] <anewton> ted: that is why this is desirable.
> > [08:23:04] <anewton> nadine: ?
> > [08:23:17] <anewton> nadine: if you only know that it is a known range
> > [08:24:34] <anewton> andy: just need to make sure that implementers
> > don't let the error show up in the emergency case
> > [08:24:58] <anewton> roger: do we agree that in addition to the URL that
> > it is desirable to have a result code?
> > [08:25:10] <anewton> henning: generally, yup/
> > [08:25:27] <anewton> is the audio being recorded?
> > [08:26:10] <anewton> henning: it is more than a status code
> > [08:26:16] <anewton> roger: additional information?
> > [08:27:13] <anewton> hannes: Validation Resolution: it MAY be possible
> > to return additional information which can be used to determine the
> > preceision or resolution of the returned sip uri, for example
> >
> > ----------------
> >
> > The meeting minutes of the interim meeting indicate:
> > http://www.ietf-ecrit.org/Interim2006/MeetingMinutes.html
> >
> > ----------------
> >
> > Issue 15
> >
> > Validation of civil location has been hanging around for a while. Should
> > it stay in the 02 draft? Andrew thought the issue was how we would do
> > validation, not whether. Brian wants to leave the language in, but would
> > like to know if people think it's adequate (we're using motivations text
> > to describe what validation means). "A successful mapping will work".
> >
> > We actually do have other requirements that talk about this (doing
> > queries at any time), but we don't describe it anywhere else.
> >
> > Are we actually validating? We don't mean NEMA validation, only asking
> > whether it's enough to get back a PSAP mapping. Passing back "here's the
> > PSAP" would be sufficient. Can we use another word? "Validation" has
> > lots of baggage. Brian wants to make sure that we can get to NEMA
> > validation - "a location that a responder knows how to get to". "A
> > location that can be sucessfully mapped to one or more PSAPs".
> >
> > We're trying to encompass both civil location and geolocation in one
> > sentence - this is one reason why it's cumbersome. If all of the city of
> > Washington goes to one PSAP but the location isn't valid, we still have
> > a problem. MSAG values have the same problem, because they carry street
> > number ranges and a "valid" street number may not exactly exist - and
> > the best MSAG validators today can't guarantee that the address exists.
> >
> > An address can be "valid enough" to get to the right PSAP, even if it's
> > not valid to respond to. Texas has one PSAP entry - so anything would
> > work as long as it's in Texas? No, the current MSAG works on address
> > ranges - but the street exists. Brian would like for this to work on
> > individual addresses, not ranges.
> >
> > Brian thinks that local PSAPs should be determining what happens for
> > various values of "invalid", since calls are going to go somewhere!
> >
> > Ted thinks that there's a lot of variation in what administrations do
> > now and will do in the future.
> >
> > Will the protocol allow us to tell that we got to the right PSAP, or
> > just got a PSAP?
> >
> > Henning - just returning a SIP URI to let someone ask "where the heck
> > are you?" isn't sufficient when we're actually routing an emergency call.
> >
> > We always get a SIP URI, we're trying to figure out what getting a SIP
> > URI actually means for an operational system.
> >
> > "I got a match on all the XML tags except this one" would be an
> > acceptable response, and this would be desirable. This could happen at
> > validation time or at emergency call routing time.
> >
> > Validation may mean "I like the only tags that I care about, and didn't
> > look at the ones I don't care about".
> >
> > Do we agree that we need a result code, in addition to a URI? Partial
> > validation may be the common case (public verifiers won't know suite
> > numbers/room numbers, for example).
> >
> > Is this MUST/SHOULD/MAY? The protocol MUST have the mechanism (whether
> > it gets used or not is up to the administration).
> >
> > And we need to be consistent in our RFC 2119 usage (which is always
> > problematic for requirements documents anyway, since the meaning is a
> > protocol-mechanism meaning, not a protocol-usage meaning). We're making
> > a lot of these requirements MUSTs, and that may make the resulting
> > protocols clumsy. If we use 2119, we should be using MUST, MAY and
> > SHOULD, not just MUST.
> >
> > Tom pointed out that some mechanisms may be provided by extensions, but
> > are not required in the base protocol.
> >
> > Henning says we're not writing a BCP, so we should consider NOT using
> > 2119 language.
> >
> > Randy suggested that we actually spell out "must support", etc. and not
> > rely on 2119. Henning - then we should have consistent terminology,
> > whether it's upper case or lower case. Randy will audit the existing
> > document, but needs input from others.
> >
> > What about returning an indicator of the resolution of the mapping that
> > is returned?
> >
> > Brian suggested text for a mechanism to indicate that a location or part
> > of location does not exist, even if it can be mapped. Should this point
> > out the invalid pieces? Aren't these administration-specific? Tags are
> > roughly self-describing, but we can't pick one hierarchy - what gets
> > returned needs to be free-form.
> >
> > James - doesn't the text say "location should be sent even if it's
> > considered unreliable?" Is this OK?
> >
> > We will leave L01 language as is, change "location validation" in
> > terminology, and we are adding two new requirements to this section.
> >
> > ----------------
> >
> > The discussions regarding Issue#15 caused us to change the following
> > requirement into two requirements:
> > http://www.ietf-ecrit.org:8080/ecrit-req/issue15
> >
> > "
> >  >   Lo1.  Validation of Civic Location: It MUST be possible to
> >  >validate a
> >  >      civic location prior to its use in an actual emergency call.
> >  >
> >  >      Motivation: Location validation provides an opportunity to help
> >  >      assure ahead of time, whether successful mapping to the
> >  >      appropriate PSAP will likely occur when it is required.
> >  >      Validation may also help to avoid delays during emergency call
> >  >      setup due to invalid locations.
> >
> > "
> >
> > to:
> >
> > "
> > Lo1X.  Validation Resolution: The mapping protocol
> > MUST support the return of additional information which can be used
> > to determine the precision or resolution of the data elements used to
> > determine a PSAP URI, for example.
> >
> > Lo1XX.  Indication of non-existent location: The
> > protocol MUST support a mechanism to indicate that a location or a
> > part of a location is known to not exist, even if a valid location-to-PSAP
> > uri mapping can be provided.
> > "
> >
> > The term validation appears only in the following sections.
> >
> > Section 1 (Introduction):
> >
> > "
> >     As used in this document, validation of location does not require to
> >     ascertain whether the location actually exists.  For example,
> >     validation might only check that the house number in a civic address
> >     falls within the assigned range, not whether that building exists at
> >     that spot.  However, such higher precision validation is desirable.
> > "
> >
> > Section 2 (Terminology):
> > "
> >     Location validation: A caller location is considered valid if the
> >        civic or geographic location is recognizable within an acceptable
> >        location reference systems (e.g., USPS, WGS-84, etc.), and can be
> >        mapped to one or more PSAPs.  While it is desirable to determine
> >        that a location exists, validation may not ensure that such a
> >        location exists.  Location validation ensures that a location is
> >        able to be referenced for mapping, but makes no assumption about
> >        the association between the caller and the caller's location.
> > "
> >
> > Section 7 (Mapping Protocol):
> >
> > "
> >     Ma22.  Validation of civic location: The mapping protocol MUST
> >        implement a method via a mapping request, that makes it possible
> >        for a mapping server to validate a civic location prior to that
> >        location's use in an actual emergency call.
> >
> >        Motivation: Location validation provides an opportunity to help
> >        assure ahead of time, whether successful mapping to the
> >        appropriate PSAP will likely occur when it is required.
> >        Validation may also help to avoid delays during emergency call
> >        setup due to invalid locations.
> >
> >     Ma23.  Validation resolution: The mapping protocol MUST support
> >        (i.e., required to implement, but not required for use) the return
> >        of additional information which can be used to determine the
> >        precision or resolution of the data elements used to determine a
> >        PSAP URI.
> >
> >        Motivation: The mapping server may not use all the data elements
> >        in the provided location information to determine a match, or may
> >        be able to find a match based on all of the information except for
> >        some specific data elements.  The uniqueness of this information
> >        set may be used to differentiate among emergency jurisdictions.
> >        Precision or resolution in the context of this requirement might
> >        mean, for example, explicit identification of the data elements
> >        that were used successfully in the mapping.
> >
> >     Ma25.  Limits to validation: Successful validation of a civic
> >        location MUST NOT be required to place an emergency call.
> >
> >        Motivation: In some cases, a civic location may not be considered
> >        valid.  This fact should not result in the call being dropped or
> >        rejected by any entity along the signaling path to the PSAP.
> > "
> >
> > I think we need to differentiate civic and geospatial location
> > information.
> >
> > Geospatial location information:
> >
> >   * Can the request be mapped to one or more PSAPs?
> >
> >     This is normal mapping protocol operation. Nothing special here.
> >
> >   * Does the address exist?
> >
> >     There is no question that this address exists
> >     if the coordinate reference system was understood.
> >
> >
> > Civic location information:
> >
> >   * Can the request be mapped to one or more PSAPs?
> >
> >     The text from Ma23 is applicable here:
> >
> >        Motivation: The mapping server may not use all the data elements
> >        in the provided location information to determine a match, or may
> >        be able to find a match based on all of the information except for
> >        some specific data elements.  The uniqueness of this information
> >        set may be used to differentiate among emergency jurisdictions.
> >        Precision or resolution in the context of this requirement might
> >        mean, for example, explicit identification of the data elements
> >        that were used successfully in the mapping.
> >
> >   * Does the address exist?
> >
> >     It is possible that a given civic address does not exist.
> >     An additional database, which contains the list of existing
> >     addresses, needs to be available.
> >
> >
> > What we can do is to be more specific about the type of behavior we want
> > from the mapping protocol.
> > Do we want the client to be able to express that the mapping server
> > should check the civic address for existence?
> > Do we want the mapping server to be able to indicate that the civic
> > address was checked against the database?
> > I don't think anything needs to be done with regard to geospatial
> > location info.
> >
> > Do we need something else?
> >
> > Ciao
> > Hannes
> >
> > _______________________________________________
> > 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

------------------------------------------------------------------------------------------------
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

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 19 Apr 2006 20:29:39 -0500

Well... this actually brings out the point I was trying to get to, that 
civic has to be to a registered or validated address, and geo can be to 
anywhere.  Meaning the two systems aren't held to the same standard.

As much as anything, I'm being mischievous today

At 07:05 PM 4/19/2006 -0500, Thomson, Martin wrote:
>I don't think that this is a real problem.  Geodetic information would be 
>evaluated against a set of PSAP boundary polygons, not converted to civic, 
>as you seem to imply (my reading).  Presumably there would be no black 
>spots not covered by PSAPs, except perhaps in international waters (and 
>I'm happy to leave that one for now).  A request for a route occurs at an 
>instant in time, with the information that is available at that time, 
>irrespective of it's accuracy.
>
>There is no real concept of validation in Phase-II E-911.  Currently, each 
>serving cell is mapped to a PSAP and the switch routes the call to the SR 
>based on the serving cell identifier.  That is, routes are statically 
>configured.  If J-STD 36-B with it's X-Y routing functionality were more 
>widely deployed, then a coarse estimate would be used (almost as coarse as 
>cell in effect) against the PSAP boundaries, which are represented as 
>polygonal areas.
>
>The point being that geodetic infomation is rarely, if ever going to 
>produce a no-route result.  That problem is one for civic 
>addresses.  Civic validation may also be a problem only in certain 
>countries; for routing, Australia would be fine with one civic field only, 
>which would make our validation database very easy to implement.
>
>Cheers,
>Martin
>
>p.s.Note that PSAP boundaries for wireline and cellular can differ 
>slightly because of this.  It's possible to reach different PSAPs from a 
>landline and mobile phone right next to each other.  And yes, misrouting 
>is very common, X-Y is supposed to help with that...a little.
>