Database Reference
In-Depth Information
occasionally exhibited a lower throughput compared to a single-channel
MAC. In this protocol [58], nodes that communicate frequently are clus-
tered together and assigned the same home (radio) channel, whereas
nodes that communicate less frequently are clustered into different chan-
nels. Hence, communication between nodes in the same cluster is fast.
When a node wants to contact another in a different cluster, it needs to
switch to that cluster's radio frequency (called its
home frequency
2
), per-
form the communication, then return to its own home channel. Since
home frequencies change from time to time, as an added robustness
mechanism, if it happens that a node cannot find its recipient on what
it believes to be the recipient's home frequency, the node starts a scan-
ning procedure, where it scans all channels looking for the recipient, and
(having found it) updates its records accordingly. This robustness mech-
anism ensures that nodes will eventually resume communication, even if
updates regarding changes in their home channel are lost.
During experimentation with the protocol, it was noticed that when
data rates were low, the multi-channel protocol outperformed a single
channel MAC protocol comfortably as it should. However, when the
data rates were increased, the protocol performed worse than a single
channel MAC. Traces from the two scenarios gave rise to the “good” and
“bad” logs, respectively. Diagnosis revealed that the problem lied with
the mechanism used by a node to find another in a different cluster. Iron-
ically, the problem was caused by the robustness mechanism described
above; namely, a node who failed to communicate with a recipient in a
different cluster would time-out and start to scan all channels looking
for it. This scanning took a long time, during which the node was not on
its home channel. During that time, other nodes
within the same cluster
who wanted to communicate with it would time-out and start scanning
as well. Eventually, their predecessors would time-out and start scan-
ning too. Hence, the scanning quickly propagated upstream from node
to node, even
within clusters
, until all nodes were scanning in an at-
tempt to find each other, instead of productively communicating. The
particular discriminative sequence of events that revealed this problem
was described in [49].
3.2 Graph Mining
While sequence mining is a powerful means for identifying chains of
events that lead to software problems, some problems are not caused
2
We use the terms “frequency” and “channel” interchangeably here to refer to a com-
munication channel defined by a different radio frequency.
