Subject: RE: DHCP options for civil locations

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 02 Jan 2003 09:59:27 -0500

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.

I do think that the "territorial" database, which is used to decide
based on a geo loc which PSAP serves the location, is being constructed,
as you say, and we want to use that.

Brian

> -----Original Message-----
> From: Marc Linsner [mailto:[email-masked]]
> Sent: Thursday, January 02, 2003 9:41 AM
> To: [email-masked]; [email-masked]
> Subject: RE: DHCP options for civil locations
> 
> 
> > [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: Marc Linsner <[email-masked]>
Date: Thu, 02 Jan 2003 12:10:23 -0500

> putting that data on the aerial photo is constructing the database.

1) The FCC requires wireless carriers to provide geo-loc only (with
accuracy) in phase II!

2) The wireless carriers do not provide the geo-loc to civil-loc
translation.  The PSAPs are implementing mapping systems that perform that
function.  PSAPs are converting geo-loc to civil-loc themselves.

3) The wireless carriers do provide funding to the PSAP in the form of a
'tax' collected on cell phone bills.  The PSAPs use their portion of this
money as they see fit (to buy mapping systems?).

4) There are mapping systems implemented that convert geo-loc to civil-loc
in realtime.  They simply have an overlay of the civil addresses in the
system and provide the closet address to the given geo-loc.  This isn't
brain surgery, you can do this in reverse, civil-loc to geo-loc, with
off-the-shelf $20 consumer products, on a nation-wide basis.

5) I don't understand your concern about aerial photographs, they are used
just like drawn maps.

6) The geo-loc LO we are proposing, takes into consideration floor number.
So, if a PSAP were to receive the geo-loc LO proposed in our draft, they
could match it to the civil address in their mapping systems and have the
floor number/building quadrant for the device making the call.  The mapping
system based on aerial photos could in fact aid a responder when trying to
get to a building in the middle of the large campus, with building names,
etc. (try and find a particular building on a large campus without a map).
Future mapping systems should/do allow local input of data, so the admin of
a large campus could provide more detailed info to the 'local' PSAP for
input into the mapping system.  This 'local' database would be far
easier/cheaper to maintain than the current hierarchy of
databases/procedures/people involved with the national databases.

7) If the PSAPs utilize geo-loc, and do the civil-loc conversion themselves,
this eliminates the backend 'national' databases that are currently the
PSAP's third highest cost (on average) of doing business.  This money would
be better spent towards updating equipment and software (intelligent mapping
systems?).

> as you say, and we want to use that.

True for SPs, but a business may not need to reference it during an
emergency call, their campus may not extend into multiple political areas.

I don't see the transmitting of civil locations going away in the near term
and multiple location data types is not a bad thing.  Geo-location should be
given a chance to prove it's worthiness.  It simply makes sense to transport
a very small piece of binary data, that is a globally accepted format, and
let the end-user/system of the data convert it to a human-usable data
structure.

-Marc Linsner-

---

From: Barr Hibbs <[email-masked]>
Date: Mon, 06 Jan 2003 13:30:07 -0800

> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Thursday, January 02, 2003 06:59
>
[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.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 06 Jan 2003 17:05:50 -0500

> for an ASP such as NeuStar of VeriSign to operate the databases on behalf of

The problem with this scheme is that it doesn't work. There are two 
pieces of information in a SIP IM or call request: the IP address of the 
caller (indirectly and unreliably) and the SIP identifier.

The IP address changes each time I log on, courtesy of DHCP. I really 
don't want to manually update my location information with Verisign each 
time I use my laptop in a hotel. (With NATs, I don't even know my 
address, making the problem yet more complicated. If I use some kind of 
back-to-back UA, the emergency call center won't even see the 
originating IP address anywhere in the request, so it is useless as a key.)

My SIP identifier stays the same, but I need to update the location 
mapping, as before. More seriously, a single identifier has multiple 
instances that can be in several locations at the same time, e.g., in my 
car, my home and my office.

Thus, you would need to introduce some globally unique device identifier 
that is carried at the application layer. I would then update some 
external database with location information, keyed on that identifier, 
and have the PSAP query this database. What exactly has been gained here 
compared to sending the information in-band? (I also need to tell the 
PSAP which of the many competing database providers they should contact, 
unless you're assuming a global monopoly.)

The DDOS issue is a red herring; creating a single database, as you 
propose, creates this problem, not a fully distributed solution. The 
device will include the location information in the call setup request. 
See 
http://www.cs.columbia.edu/~hgs/sip/drafts/draft-schulzrinne-sipping-sos-03.txt 
for the details. Requests to external databases also greatly increase 
the failure potential, since I now need yet another server to work 
correctly. In other words, if either the PSAP or my laptop-in-hotel 
can't get to this magical database, the mechanism fails. This mechanism 
needs to work globally, not just in one country, further complicating 
the problem. (My laptop is configured to update the US database; if I 
make a call in Australia, the Australian PSAP has to contact the US 
database.)

I'm somewhat perplexed why you consider manual update a superior option, 
compared to techniques that actually have a chance of working in a 
distributed fashion.

Henning