Subject: RE: DHCP options for civil locations

From: [email-masked]
Date: Thu, 02 Jan 2003 11:04:22 -0500

One small thought on the civil vs lat/long location issue. I am from the
GIS/Location Services World. We have been dealing with this issue for some
time. I have also been able to attend briefings by various States on how they
wish to implement the functionality required to incorporate new location data
from celluar telephones (whether cell-id, triangulated, or GPS).

In the majority of the cases, they are looking to the application software to
take the lat/long (or other coordinate information) as input. This input is
used in a "reverse geocoder" application to return the civil location
information as well as possible routing directions. Reverse geocoding in GIS
and Location Services is the transformation of a coordinate into a street
address, police precinct, distance to and location of a landmark or some other
well known location description (civil location)and so forth. These
applications therefore rely on strong content repositories of civil location
descriptions. Fortunately, there are excellent commercial and government
sources for this content in many countries.

Regards

Carl Reed
OpenGIS Consortium

On Thu, 02 Jan 2003 09:40:35 -0500 Marc Linsner <[email-masked]> wrote:

> > [rbh] sorry, I thought that we were coming to
> agreement.  I definitely
> > agree with your assertion that civil data is
> generally more useful for
> > emergency responders than latitude and
> longitude, even with the inevitable
> > imprecision.
> 
> We should probably let the emergency responders
> offer an opinion on civil
> location verses geo-location (lat/long).  It
> would make one think that since
> all wireless phase II location information is
> arriving at the PSAP as
> geo-location suggests that the emergency
> responders may already be able to
> handle geo-location type data.  I agree that in
> a campus environment, having
> the civil location, known to locals, would
> benefit the responders, ie -
> 'payphone in section G12 of football stadium'. 
> But, IMO, the downsides of
> the civil location scheme - backend databases
> required to provide call
> routing and record storage - warrant an attempt
> at a system that may be able
> to utilize common tools with well-known data
> types (note: economies
> associated with such a system, in addition to
> other applications for using
> this data).  Geo-loc would eliminate the MSAG
> database and the ALI database.
> Geo-loc would require a call routing system
> based on a territorial database
> whereas 'anything inside this box - send the
> call to XYZ PSAP'.  This
> territorial database would be much easier to
> maintain than the current MSAG
> database - only political boundary changes
> would cause database changes.
> BTW, such a territorial database is 'in trial'
> right now. Currently, any new
> street or address number extensions cause MSAG
> updates.  Most mapping
> systems are actually aerial photographs, which
> when coupled with floor data
> (as outlined in our geo-loc LO draft) could aid
> the responders in finding
> the caller in section G12 of the football
> stadium.  I believe there is room
> for both location data types, let the best one
> win (we can always take back
> the dhcp option number from the loser!).
> 
> > [rbh] agreed, perfection is probably not
> possible, but I came at this
> > topic from a review of an Internet-Draft that
> specified latitude and
> > longitude with a maximum precision of
> approximately 3 mm.  That's why I
> > questioned the difficulties in obtaining and
> maintaining the location data
> > for a DHCP server to distribute to its
> clients.
> 
> I don't believe anyone is suggesting a
> requirement that geo-loc data for
> emergency calling purposes must be 3mm
> resolution.  In fact, in the sematics
> draft, we gave a resolution value that closely
> matches desired emergency
> responder resolution of 7000sq.ft.  The high
> resolution in the draft is an
> attempt to future-proof the LO, somewhat. 
> Since mapping system vendors are
> claiming 3cm resolution in current products,
> maybe we should add a few more
> bytes to the geo-loc LO.
> 
> >
> > [rbh] not at all.  I just want to be sure
> that the realities of the
> > provisioning and database maintenance process
> are not overlooked in the
> > move to supply location information via DHCP.
>  My instincts tell me that
> > the administrative burden will overwhelm many
> implementors.
> 
> This burden isn't be caused by the data type,
> it's caused by local
> policy/regulation.  We are attempting to
> provide tools that will assist with
> the burden. In locations that currently require
> PBX admins to provide
> location information for each phone, the admins
> are already tracking phone
> locations - the burden is already in place! 
> Obviously in areas where there
> is no policy/regulation forcing an admin to do
> this, we are suggesting that
> it could be 'turned off' within DHCP.
> 
> >
> > [rbh] I don't follow liability torts at all,
> but I don't believe there has
> > been a precedent-establishing case to date
> (involving land lines or
> > cordless phones) or this would be a moot
> point:  in the aftermath of a
> > successful action there would have been
> product modifications (or
> > withdrawal of products from the market) and
> new self-registration
> > procedures as well as a flurry of retrofits
> and records clean-up.  I'm
> > more inclined to believe that legislation
> mandating the provisioning of
> > location information to aid emergency
> services will be widely adopted, but
> > with limitations on liability and a long
> timeframe for implementation to
> > be completed.
> >
> 
> It's fairly common knowledge that LECs are
> exempt from liability from a
> failure in the 911 network.  The LECs wouldn't
> provide the service if they
> couldn't escape liability in the event of a
> network failure.
> 
> > [rbh] this is perhaps the only area where we
> truly disagree:  I contend
> > that implementation issues are crucial to
> successful and widespread
> > deployment of standards.  There are several
> RFCs, sometimes covering
> > entire services, that are not widely
> implemented because of the difficulty
> > of administering them.  For the geolocation
> service to be successful, it
> > must not be difficult to setup and operate. 
> I am advocating the careful
> > consideration of administrative effort for
> any proposed service so that it
> > does not burden system and network
> administrators, installers, and
> > technicians.
> 
> Not much disagreement with this statement. 
> That's why we think that
> building the location database (wire map) 'one
> time', then utilizing over
> and over again, automatically, at host
> configuration time, is a good thing.
> 
> -Marc Linsner-
> 
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 06 Jan 2003 17:07:24 -0500

Only if the PSAPs get the data from the new entity.
If the owner of the sipphone has to do it, then you need
to have reasonable assurance that, during the emergency
call, the UA has access to the database.  That's not a
good bet.

The current mess for PBXs, where corporates pay pretty 
stiff fees to have their extension-to-building/floor/room
data updated should not be repeated.

I'm with Henning.  As a practical matter, right now, most
enterprises have:
	Jack to room information
	Phone extension to room information, currently (or soon
		soon to be) reported to an external database
	DHCP
To put the data together, and have it reported in any reasonable
manner to the PSAP in an emergency call is pretty reasonable.
To make that the mechanism by which service providers for smaller
customers (homes,...) doesn't seem very onerous.

Brian

> -----Original Message-----
> From: Barr Hibbs [mailto:[email-masked]]
> Sent: Monday, January 06, 2003 4:30 PM
> To: [email-masked]
> Subject: RE: DHCP options for civil locations
> 
> 
> 
> > -----Original Message-----
> > From: Rosen, Brian [mailto:[email-masked]]
> > Sent: Thursday, January 02, 2003 06:59
> >
> > I'm not an expert here, but I believe that the wireless folks have
> > been required to provide a database that translates geo loc to
> > civil loc.  PSAPs require civil loc.  I expect that the 
> actual responder
> > would like both - he wants to know the street address, but 
> he probably
> > can carry a GPS system that could confirm he is exactly where he is
> > supposed to be.  Requiring that the PSAP maintain the database is
> > probably impractical; the politics are that new fancy systems like
> > VoIP have to pay the costs of new technology -- the 911 
> (fill in your
> > local number here) system doesn't do that.  It's not reasonable to
> > do translation in real time with an aerial photo, you need 
> to be able to
> > translate a geo loc into a specific street number, floor, etc, and
> > putting that data on the aerial photo is constructing the database.
> >
> [rbh] I agree that VOIP systems will have to provide the 
> infrastructure to
> support services such as E911, ANI, and Caller-ID, but I 
> think we're all
> struggling to determine which entity (ASP, ISP, customer network
> administration, or other) is best suited to do so.  After all of the
> discussion, I'm beginning to believe that there is a niche 
> opportunity here
> for an ASP such as NeuStar of VeriSign to operate the 
> databases on behalf of
> VoIP clients.
>