Eunah et al.
I would be much happier with this document if star-connected nodes were
the exception rather
than the rule. Can we add some more links in there so the reader will
get used to the idea of meshes rather than trees? Most people who have
done commercial deployments will tell you that stars and trees are
lethal for reliability. As far as RFD vs. FFD goes, does anyone even
make an RFD?
I'd also recommend an update to the "typical characteristics" in section 1.
* Under "low power" you're mixing RF transmit power ("up to 1000mW") and
radio power consumption ("between 10 mW and 20mW"). Also, there's
exactly one 802.15.4 radio that falls into that range (the DN2510). The
rest are all substantially higher.
* The specs on memory and processor horsepower are from the golden age
of academic wsn research, and are almost a decade out of date. Look at
what Freescale, Atmel, Jennic, etc. are shipping in volume. They are
32-bit cores (typically ARM7) running at tens of MHz, with tens of kB of
RAM.
Section 3:
* Connectivity: I disagree with the association of "sleeping mode" with
"intermittent" connectivity. There are many L2 protocols that allow
tradeoffs between duty cycle and link BW. I would not call those nodes
that sleep >99% of the time intermittent - they just have lower
effective bit rate links. In particular, reading down in 4.1.1 the
description of industrial monitoring connectivity as "always on for
crucial processes, otherwise intermittent" does not fit with what's
happening in the real world, and would tend to mislead someone not well
versed in the field.
* "several traffic patterns may be overused in LoWPANs" - overused?
* "primordial" - I've seen networks like this, but I don't think that's
what you really mean
4.1.2 Figures 4 and 5
You confuse "mesh" with "multi-hop" in your captions. Figure 5 has no
meshing at all. maybe keep the caption, and put in some real meshing?
Same thing for figure 6 and 7. I strongly disagree with the statement
in 4.2.1 that this would work with a star topology, or a hierarchical star.
4.2.1
* "The network configuration and forwarding/routing tables are changed
only in the case of node failure".
Huh? Forwarding/routing tables will be updated *regularly* in a network
like this due to connectivity changes. The RF environment is not
static, even on a 'static' structure like a bridge, and even with line
of sight. Every piece of metal on a bridge looks like a mirror to RF,
and all of the mirrors move a little.
Overall, I'm concerned that this document does not feel to me like it
embraces the practical knowledge from real world deployments from *many*
different companies using *many* different protocols. Did you talk to
Arch Rock, Control 4, Dust, Ember, Emerson, Streetline, ...? We're not
in the academic phase anymore - we've actually got lots of real-world
data now, and much of it seems to be at odds with what's in this document.
ksjp
Geoff Mulligan wrote:
Folks,
This note formally starts the WG Last Call for comments on
draft-ietf-6lowpan-usecases-03.txt, "Design and Application Spaces for
6LoWPANs".
The document can be found at:
http://www.ietf.org/id/draft-ietf-6lowpan-usecases-03.txt
The document is intended to be submitted by this Working Group to the
IESG for publication as an Informational Document.
Please review the document carefully (one last time), and send your
comments to the 6lowpan list. Please also indicate in your response
whether or not you think this document is ready to go to the IESG.
This Last Call will end on Thursday 1 October 2009 at 2359 UTC.
Thanks,
Geoff & Carsten
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
