Re: Geopriv WG - meeting 5-6 Jun, other news

From: Aleksandar Gogic ^lt;>
Date: Fri May 17 2002 - 21:59:32 EDT

At 08:44 PM 5/16/2002 -0400, Richard Shockey wrote:
>At 05:00 PM 5/16/2002 -0500, James M. Polk wrote:
>First let me thank you for a very thoughtful answer ..this is exactly the
>kind of proper technical discussion I've been hoping to see here.
>>I share many of your views written here. I would add a few requirements
>>such as altitude, velocity and vector (better than direction).

"Vector" may be a slight improvement, but perhaps more appropriate terms
would be those used in aviation (navigation), such as "Heading" (relative
to True North). Along the same lines ... "horizontal velocity" and
"vertical velocity".

>>TTL should
>>be coupled with the Time of source sample because the LO of a Target might
>>be for a stationary object (infinite TTL) vs. a Rocket (changing quite
>works for me ... great idea... now what about the Policy Object :-)
>>I question how you determine "confidence" within the LO Requirements. Is
>>the policy Rule Maker going to tell me that I should only have a 50%
>>confidence factor of the answer I just got from some location server when
>>trying to determine your location, or should that be in the background?
>>Shouldn't the Rule Maker (Target's Policy) determine how granular the
>>information is going to be based on who's asking for it?

Granularity of location description (precision) should be independent from
confidence, it seems to me. The way I look at this can be illustrated as
follows. The location client may be entitled to receive location
information down to, e.g. 100 meters. That is granularity, and this is
what should be the key parameter in privacy rules. Confidence is the
degree of certainly to which it can be stated that the object is located
within the perimeter of the allowed precision. If the confidence level is
too low for the purpose of the client, it may make another request that is
coarser, until it either satisfies the confidence level, or the perimeter
becomes too coarse. Confidence is mostly based on measurement, but one can
get really fancy here. For example, based on the elapsed time since the
last available data (e.g. 30 minutes ago), and the assumed mode of
transportation that the target uses (car), and known traffic conditions in
the direction of travel since the time of last measurement (North on
Interstate 405, near Santa Monica Boulevard exit) it may be stated with the
confidence of 90% that the target has not reached Burbank. This of course
is just an illustrative example. I believe that the confidence should not
be confused with integrity of the data. In principle, I believe that the
location information should always have full integrity, i.e., deceitful
information should not be used to protect privacy.

>Yes ..I have to admit that I am struggling with how to express the concept
>of confidence in the accuracy of the location data source.. if you look at
>the problem set in wireless it might help in determine what may or may not
>be needed here ..the known legal requirements for location in wireless are
>within 100 meters as set by Congress in the US ..I have no accurate data
>on what the Europeans are requiring in the GSM environment ..however that
>said the two solutions are A. GPS but that does not work well in buildings
>and B. Triangulation from the base station but that generally requires at
>least 2 points which is not possible if you are roaming along a highway
>where the base stations are linear.

The two methods described are commonly used for location determination in
wireless. They are expected to work well, in fact they do already work on
many networks, when combined as stated here. When moving along a lonesome
highway with only a string of base stations, generally, good visibility to
satellites exists. Using time of arrival methods from two base stations
could even be sufficient for a good measurement, when supplemented by
topographic information (e.g. it is unlikely that the target has driven off
into a roadless desert, or even less so into a mountainous forest),
yielding good confidence in a relatively fine precision perimeter.

>This is a highly subjective data point that SHOULD be under control of the
>Rule Maker ..but the question is does that entity have sufficient smarts
>to evaluate the criterion necessary for determining a confidence level in
>the data presented.
>>I don't know if I agree with your PUSH preference at this time, except in
>>times of emergency -- in which case I believe the LO should be part of the
>>original INVITE packet in SIP.
>Perhaps but not all SIP calls require location .. I see it as a separate
>session the PSAP might be able to request the data separately ..again this
>is a fruitful line of discussion.
>>Has anyone talked to the FCC and NENA (in the US, and counterparts in other
>>countries) about their requirements regarding disclosure of information?
>>One good lawsuit might very well change (or obsolete) this protocol if its
>>written with the constraints of these requirements and past views.
>well we do have some fine people on this list who have had discussions
>with a variety of entities looking at this I know this is a strong area of
>interest with Henning Schultzrinne ... certainly since I live in the DC
>area does Allison it would be a simple task to sit down with folks
>and get a clearer picture of what is really required here.
>I have no doubt after numerous conversations with FCC officials and US
>State PUC types that they are going to demand an answer to these questions
>or they will impose a solution as we have seen Congress do in the wireless
>>"People generally demand more respect for their own rights than they are
>>willing to allow for others"
>>James M. Polk
>>Senior Consulting Engineer
>>Office of the CTO
>>Cisco Systems
>>2200 East President George Bush Turnpike
>>Richardson, TX 75082 USA
>>w) 972.813.5208
>>f) 972.813.5280
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>Richard Shockey, Senior Manager, Strategic Technology Initiatives
>NeuStar Inc.
>45980 Center Oak Plaza Bldg 8 Sterling, VA 20166
>1120 Vermont Ave NW Suite 400 Washington DC 20005
>Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237
><mailto:> or

Aleksandar Gogic
QUALCOMM Incorporated
5775 Morehouse Drive
San Diego, CA 92121-1714
Office: +1 858 651 5386
Mobile: +1 858 213 7368
Received on Fri May 17 22:01:09 2002

This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:23 EST