Per your question, our current implementation
uses standard ZigBee algorithms. ZigBee bases path costs on RSSI
only. While nice and simple; unfortunately we feel this approach
doesn't necessarily pick the best communication paths, only the ones that
have a strong signal. Mukul did a lot of simulation work for us on
this and helped drive us to this conclusion.
Our product was developed and deployed
in 2006. We used what is termed the 'ZigBee 2006 Stack'. Since
that time, ZigBee has developed the 'ZigBee PRO' stack which will in time
subsume the ZigBee Stack. ZigBee PRO selects paths based on the best
symmetric path found. I believe asymmetric paths are discarded or
only used as a last resort. Unfortunately, I have no empirical or
simulation data on this metric. Maybe Richard can provide some insight
on this approach since I believe it was championed by Ember.
Jerry
JP Vasseur <jvasseur at cisco.com>
10/08/2009 12:53 AM
To
Jerald.P.Martocci at jci.com
cc
IETF ROLL <roll at ietf.org>, Kris
Pister <kpister at dustnetworks.com>, "???[??????]" <mjkim at kt.com>
I am not sure what you're asking, but I 'll hazard a guess. Let me
know if my comments make sense.
I believe you are saying that the Metrics ID specifies some minimization
strategies and are asking if we should add additional strategies for 1)
latency and 2) link reliability.
That's right. This document specifies the list of metric
used by RPL to build the DAG (parent selection).
As for latency, I am presuming this
would be analogous to a QoS strategy. That is move packets from point
'a' to point 'b' in the minimal amount of time. The Building
Requirements called out a QoS requirement to assure high priority packets
(e.g. Fire Alarms) could traverse the LLN faster than other messages.
Yes, I would just like to clarify something here. We are
not discussing QoS, which strictly speaking refers to the set of mechanisms
used along the forwarding path (scheduling, congestion management such
as RED, ...) once the path is computed. For example, you could compute
the DAG based on a reliability metrics and provide differentiated QoS to
traffic forwarded along this path.
The question here is whether we should use a QoS metric
to build the DAG and if yes what should be the metric. Several IETF ago,
we agreed that queueing delays were not a good idea due to their high fluctuation.
Furthermore, it does not make much sense when nodes have 1 packet buffer
...
This is why the proposal was here to use latency in order
to reflect the MAC latency, which may indeed vary by an order of magnitude.
As for Link Reliability, I also vote
'yes'. I am presume that Link Reliability is akin to ETX. That
is moving packets from point 'a' to point 'b' with the best possible change
of success of arrival with no errors.
Right.
In the implementations that you deployed, did you use
such "QoS" and reliability metric ? In which units ?
Thanks.
JP.
So I think I have answered your questions. If not, please let me
know.
We would appreciate your feed-back on RPL routing metrics.
Now that RPL is stabilizing it is time to move forward with the METRIC
I-D. The next revision will be a major one, with packet encoding, processing
rules, etc.
We discussed and agreed some time ago on several links and nodes metrics
(also required according to our requirement IDs).
Still, there are a few metrics for which we would like to know whether
you think that they should be specified.
4.2. Latency
As with throughput, the latency of many LLN MAC sub-layers can
be
varied over many orders of magnitude, again with a corresponding
change in current consumption. Some LLN MACs will allow the
latency
to be adjusted globally on the subnet, or on a link-by-link basis,
or
not at all. Some will insist that it be fixed for a given
link, but
allow it to be variable from link to link. For efficient
operation,
nodes must be able to report the range of latency that their links
can handle, and the currently available latency.
4.3. Link reliability
In LLNs, link reliability is degraded by external interference
and
multi-path interference. Multipath typically affects both
directions
on the link equally, whereas external interference is sometimes
uni-
directional. Time scales vary from milliseconds to days,
and are
often periodic and linked to human activity. Packet error
rate can
generally be measured directly, and other metrics (e.g. bit error
rate, mean time between failures) are typically derived from that.
In addition:
Node Memory resources:
Memory is a critical node resources in presence of constrained nodes. Is
there a need to report node memory resources as a routing metric/constraint
?
Node CPU resources:
CPU duty cycle for virtually all LLN applications to date is well below
10%, and the trend in low power embedded systems is to more capable processors
rather than less. Computational speed is not expected to be a limiting
factor in routing in LLNs. Is there a need to report node CPU resources
as a routing metric/constraint ?
Link Security metrics
