RE: [dhcwg] Working Group Last Call: Location Configuration Information for GEOPRIV

"Marc Linsner" <mlinsner@cisco.com> Thu, 03 July 2003 00:27 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05464; Wed, 2 Jul 2003 20:27:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XrwD-0005fM-4S; Wed, 02 Jul 2003 20:27:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XrvS-0005eS-TJ for dhcwg@optimus.ietf.org; Wed, 02 Jul 2003 20:26:19 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05352 for <dhcwg@ietf.org>; Wed, 2 Jul 2003 20:26:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XrvQ-00072p-00 for dhcwg@ietf.org; Wed, 02 Jul 2003 20:26:12 -0400
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19XrvQ-00071j-00 for dhcwg@ietf.org; Wed, 02 Jul 2003 20:26:12 -0400
Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 02 Jul 2003 17:22:20 -0700
Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h630PYf0012422; Wed, 2 Jul 2003 17:25:40 -0700 (PDT)
Received: from mlinsnerzk7abh (ssh-sjc-1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA25496; Wed, 2 Jul 2003 17:25:33 -0700 (PDT)
From: Marc Linsner <mlinsner@cisco.com>
To: "'Abbott, Nadine B.'" <nabbott@telcordia.com>
Cc: dhcwg@ietf.org, geopriv@mail.apps.ietf.org, "'Defazio, Carol'" <cdefazio@telcordia.com>
Subject: RE: [dhcwg] Working Group Last Call: Location Configuration Information for GEOPRIV
Date: Wed, 02 Jul 2003 20:25:32 -0400
Message-ID: <000501c340f9$9ea454f0$220d0d0a@mlinsnerzk7abh>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
In-Reply-To: <F0CB7F62D783BF40AD93882BB817F245129721@nvc-dts-exs01.cc.telcordia.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 7bit
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Yes, we did look at the T1.628 geo-loc format.  As John Schnizlein
already stated, we found it to be inefficient in many respects.  We also
discussed other uses of our newly described format and decided it needed
to be able to define a higher resolution than what is allowed by T1.628.

The new format: better than 7 decimal places of degrees of resolution;
ability to identify floors of a building (something that is impossible
for a PSAP to accomplish with a simple altitude value); ability to state
the resolution (accuracy) of the location value from 1/6 of the globe to
~3mm.  All this in only 16 bytes!

The bottom line: The application at the PSAP will need to be able to
interpret the new format.  Interpretation of this format should be
relatively easy for today's class of cpus.  At this point, looking at
the length of the data object should be a good clue for a GIS
application programmer to decide which format they're dealing with.  Or,
a few short subroutines to run against the object will be able to decide
in a short time the format.  I don't foresee the need to do any
conversion outside of the PSAP GIS mapping software.  If a network
routing node needs to perform a lookup based on the new format,
conversion to the needed format for lookup will be easy at that point
also or by the lookup service provider.  After all, MS Word can
understand text, word, html, rtf, etc. docs; a $50K GIS package should
be able to handle a couple of different data formats.

-Marc Linsner-

 
> For wireless 9-1-1 calls, the geodetic location is provided from the
> wireless carriers in a binary coded form over SS7 (ISUP or TCAP/E2,
> carried
> in Calling Geodetic Location parameter; see ANSI T1.628-2000 for the
> coding
> of the CGL--similar, but not the same as the DHCP-LO).  The location
> information is processed by an E9-1-1 Database for delivery to Public
> Safety
> Answering Points (PSAPs).
> The geodetic location information that is provided to 9-1-1 Public
Safety
> Answering Points via queries to these E9-1-1 DBs uses the following
NENA
> formats:
> 
> Longitude:
> 11 bytes; Numeric;
> Longitude/X coordinate. Right Justified; pad field with zeros to left
of
> decimal degrees. +long: east of Greenwich; -long: west of Greenwich.
(Can
> be used
> for wireline as well as wireless) Sample: +000.######
> 
> Latitude
> 10 bytes; Numeric;
> Latitude/Y coordinate. Right Justified; pad field with zeros to left
of
> decimal
> degrees. +lat: north of equator; -lat: south of equator. (Can be used
for
> wireline as well as wireless) Sample: +00.######
> 
> Elevation
> 5 bytes; Numeric;
> Elevation/Altitude indicated as height above mean sea level, measured
in
> meters (Can be used for wireline) Sample: #####
> 
> Datum
> 2 bytes; alphanumeric;
> Specifies the map projection and coordinate system recommended for the
> display of the Longitude and Latitude coordinates. Two systems are
> commonly used for North America. The code 83 identifies North American
> Datum for 1983 (NAD83). Code 84 identifies the World Geodetic System
> for 1984 (WGS84). Other codes may be added as additional datum become
> available through authorized entities.
> Where x =
> 83 = NAD83
> 84 = WGS84
> 
>
************************************************************************
**
> **
> ***********
> 
> 
> For a 9-1-1 call, if IP devices are populated with coordinate
information
> in
> a different format from that expected by PSAP mapping applications,
then
> somewhere between caller and PSAP, the geodetic location information
> provided by the DHCP location object procedures will need to be put
into a
> format that can be processed by PSAP applications.  If you assume that
the
> location object information is routed via the E9-1-1 DBs, perhaps the
> conversion could be performed there.  If you envision that geodetic
> location
> is carried with the call establishment signaling, where do you assume
that
> the conversion between the DHCP-LO format and the formats expected by
PSAP
> applications will take place?
> 
> Thanks,
> Nadine Abbott
> Telcordia Technologies
> 



_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg