Responses inline.
On 2011-04-25 at 16:23:24, Geoff Thompson wrote:
> I was asked in Prague to review
> [draft-ietf-geopriv-held-measurements-03] for the IEEE 802
> considerations.
Thanks very much for the review.
> 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.
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.
> 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.
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
> 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).
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).
> In section 5.6, DSL Measurements {Full 2 paragraphs of text is
> 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.
> RE: 11.2. Informative References
> [ANSI-TIA-1057] I think this can be deleted now that the capability is
> included in 802.1AB
See above.
> [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(tm)-2009
The (tm) is a bit of a challenge, but I got the rest. I'll let the lawyers sort out the trademarks.
> 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.
I don't think that a specific 802.3bc reference is necessary, given the nature of the parameters defined therein.
Cheers,
Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
