Subject: [Geopriv] Review of draft-ietf-geopriv-held-measurements-03

From: Geoff Thompson <[email-masked]>
Date: Sun, 24 Apr 2011 23:23:24 -0700

I was asked in Prague to review 
[draft-ietf-geopriv-held-measurements-03] for the IEEE 802 considerations.
My comments follow:

In section 5.1 LLDP Measurements regarding the note:
I believe that technical capability originally specified in LLDP-MED is 
now included in the 2009 revision of 802.1AB (IEEE Std 802.1AB - 2009).
Further, the 802.3 specific TLVs specified in 802.1AB clause 6.3 have 
been superceded by IEEE Std 802.3bc - 2009 (as anticipated in Note 2 of 
that sub-clause). Thus I suspect that the reference to LLDP - MED and 
ANSI-TIA-1057 should be removed.

In the text below Figure 6, the measurement set seems to assume that 
both the wifi end station and the access point are stationary. I'm not 
clear whether we are attempting fully cope with the "in motion" case. We 
can (at least) detect it and put in an indicator (e.g. some sort of 
flag, etc. for whether location is changing within some time/distance 
parameters).

Re: Page 19, flightTime: I don't believe that the statement "Measurement 
of this value requires that stations synchronize their clocks" is 
correct, at least for the nominally static case. It would be true if the 
result were based on a 1 way measurement. However, if it is the average 
of a 2 way measurement then any difference in local time-of-day would be 
cancelled out (assuming matching clock rates). It would seem more useful 
to allow the lesser constrained case.

In section 5.6, DSL Measurements {Full 2 paragraphs of text is 
reproduced, my comments are in curly brackets}:

Digital Subscriber Line (DSL) networks rely on a range of network 
technology {"technology" should be plural}. DSL deployments regularly 
require cooperation between multiple organizations. These fall into two 
broad categories: infrastructure providers and Internet service 
providers (ISPs).
Infrastructure providers manage the bulk of the physical infrastructure 
including cabling. End users obtain their service from an ISP {Insert: 
"(Who may or may not be be the same entity as the infrastructure 
provider)"}, which manages all aspects visible to the end user including 
IP address allocation and operation of a LIS. See [DSL.TR025] and 
[DSL.TR101] for further information on DSL network deployments and the 
parameters that are available.

Exchange of measurement information between these organizations is 
necessary for location information to be correctly generated. The
ISP LIS needs to acquire location information from the infrastructure 
provider. However, {Insert: "since"} the infrastructure provider has 
{Replace" "has" with "may have"} no knowledge of Device identifiers, it 
can only identify a stream of data that is sent to the ISP. This is 
resolved by passing measurement data relating to the Device to a LIS 
operated by the infrastructure provider.

RE: 5.6.3. Ethernet VLAN Tag Measurements
There are several types of Ethernet VLANs in the world. This information 
seems to be specific to a particular VLAN specification that does not 
seem to be referenced.

RE: 11.2. Informative References
[ANSI-TIA-1057] I think this can be deleted now that the capability is 
included in 802.1AB

[IEEE.8021AB] To both update the citation and correct its form, it 
should be:
"IEEE Standard for Local and metropolitan area networks— Station and 
Media Access Control Connectivity Discovery" IEEE Std 802.1AB™-2009

Since the specifications for the 802.3 TLVs in 802.1AB-2009 have been 
superceded by IEEE Std 802.3bc - 2009 a citation should be added for it. 
Since the current correct name for that standard is SO long and 
unwieldly (and the next revision will shorted the 802.3 title to 
"Standard for Ethernet") I suggest
"IEEE Standard for Local and metropolitan area networks— Part 3: 
Amendment 2: Ethernet Organizationally Specific Type, Length, Value 
(TLVs)" IEEE Std 802.3bc™-2009

Both 802.1AB - 2009 and 802.3bc - 2009 can be obtained at no charge from 
http://standards.ieee.org/about/get/

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 29 Apr 2011 13:49:21 +0800

Hi Geoff,

Responses inline.

> [draft-ietf-geopriv-held-measurements-03] for the IEEE 802 

Thanks very much for the review.

> I believe that technical capability originally specified in LLDP-MED 
> is now included in the 2009 revision of 802.1AB (IEEE Std 802.1AB - 2009).
> been superceded by IEEE Std 802.3bc - 2009 (as anticipated in Note 2 
> of that sub-clause). Thus I suspect that the reference to LLDP - MED 
> and

Thanks for the update.  This draft actually predates all of that work, so I've obviously got to play a bit more catchup.

Looking at 802.1AB-2009 and 802.3BC, it doesn't look like the location TLVs are present.  Since those TLVs are of the most interest, I've retained the ANSI reference until I find the right reference.

> clear whether we are attempting fully cope with the "in motion" case.

Detecting the location of a mobile device is considerably more difficult, but still possible with the measurements provided.  Since each measurement is timestamped, multiple measurements might be used to reveal motion.

I anticipate that to do moving devices justice, there are probably more parameters required than what are described.  Though what is included is what I understand to be the "state of the art".  This is universally true - the GPS parameters could also be used to determine velocity, but they probably aren't especially good at it.

> We

The best way to indicate that parameters are changing is to include multiple values at different times.

As I understand it, implementations tend to make some assumptions about devices, including the (inadvisable) assumption that a device is stationary.  I tend to think that a flag sends the wrong message - the default assumption should be that the target is moving, in the absence of strong evidence to the contrary. :)

> Re: Page 19, flightTime: I don't believe that the statement 
> "Measurement of this value requires that stations synchronize their 
> clocks" is correct, at least for the nominally static case. It would 
> be true if the result were based on a 1 way measurement. However, if 
> it is the average of a 2 way measurement then any difference in local 
> time-of-day would be cancelled out (assuming matching clock rates). It 
> would seem more useful to allow the lesser constrained case.

I'm not the expert in this, but I'm assured by those who are (I've spoken to both Gabor Bajko and internal experts on this) that this is the current direction.  This is consistent with my reading of Annex of V of the 802.11v specifications.

The draft originally used a round trip time measurement, but the problem with using round trip timing is that scheduling delays add a random offset to the response.  It turns out that it's easier to use flight time for WiFi.  There are still challenges in measuring flight time and acquiring good synchronization, but I'm told that there are various solutions that reduce the errors to the point that the resulting range measurement is accurate enough to use (i.e., sub-metre).

> reproduced, my comments are in curly brackets}:

Thanks.
 
> RE: 5.6.3. Ethernet VLAN Tag Measurements There are several types of 
> Ethernet VLANs in the world. This information seems to be specific to 
> a particular VLAN specification that does not seem to be referenced.

You can find these labels defined in DSL Forum TR-101.  They aren't labels that would be known to someone with IEEE background.  The Ethernet deployments for DSL use multiple layers of VLAN for various reasons beyond my ken, but here's what TR-101 defines these as:

C-Tag 	The innermost VLAN tag as defined in IEEE 802.1ad and having an EtherType value of 0x8100
S-Tag		The outermost or single VLAN tag as defined in IEEE 802.1ad.

> [ANSI-TIA-1057] I think this can be deleted now that the capability is 

See above.

> "IEEE Standard for Local and metropolitan area networks- Station and 
> Media Access Control Connectivity Discovery" IEEE Std 802.1AB(tm)-2009

The (tm) is a bit of a challenge, but I got the rest.  I'll let the lawyers sort out the trademarks.

> superceded by IEEE Std 802.3bc - 2009 a citation should be added for 

I don't think that a specific 802.3bc reference is necessary, given the nature of the parameters defined therein.

Cheers,
Martin