[ieee africon 2007 - windhoek, south africa (2007.10.26-2007.10.28)] africon 2007 - comparing...
Post on 27-Jan-2017
222 Views
Preview:
TRANSCRIPT
1
Abstract—Selecting a routing protocol for a wireless sensor
network depends on various factors like the network lifetime,
success rate and the number of nodes in the network. This
paper compares four popular routing protocols currently used
in wireless sensor networks. The experimental setup is
described, after which the various protocols are compared and
evaluated.
Index Terms—routing protocols, wireless sensor networks,
multihop routing, power consumption
I. INTRODUCTION
routing protocol is required when a source node can not
send its packets directly to its destination node but has
to rely on the assistance of intermediate nodes to forward
these packets on its behalf. Although many protocols exist
for traditional ad hoc wireless networks, none of them are
suitable to the unique requirements of wireless sensor
networks.
Routing protocols can be divided into two groups,
proactive and reactive routing protocols [1]. With proactive
routing a routing table is generated at each node, so that
routing information is kept for every node in the network.
This is used in traditional link-state and distance vector
routing protocols, with the DSDV (Destination-Sequenced
Distance Vector) protocol being proposed for wireless
sensor networks.
With reactive routing no routing tables are generated and
route discovery is done as needed. The route information is
then kept for future reference. Existing reactive protocols
include AODV (Ad hoc On-demand Distance Vector) and
DSR (Dynamic Source Routing). The problem with these
protocols is that they minimize the total energy consumed in
the network, but drain energy along paths chosen for
minimum energy consumption. Network partitioning
happens when some nodes in the network are drained from
their battery energy more quickly than others, leading to
some parts of the network being cut of from the rest of the
network.
In this paper the following routing protocols are simulated
Manuscript received March 3, 2007.
G. Niezen and G.P. Hancke are with the Department of Electrical,
Electronic and Computer Engineering, University of Pretoria, South Africa.
(e-mail: gniezen@ieee.org, g.hancke@ieee.org).
I.J. Rudas and L. Horváth are with Budapest Polytechnic, Hungary.
(e-mail: rudas@bmf.hu, laszlo.horvath@nik.bmf.hu)
The authors acknowledge the grant provided by the National Office of
Research and Technology (Hungary) and the Agency for Research Fund
Management and Research Exploitation (KPI) (Hungary) in the Hungarian-
South African Intergovernmental Science and Technology Cooperation
Programmes (project number ZA-37/2006). The authors also acknowledge
the grant provided by the OTKA Fund for Research of the Hungarian
Government (project number K 063405).
and evaluated:
� Flooding protocol - no routing tables are kept and
messages are broadcast across the network,
� TinyOS 1.x Multihop Routing – a shortest-path-first
algorithm with a single destination node (the sink node)
and active two-way link estimation,
� Low-Energy Adaptive Clustering Hierarchy (LEACH)
– a clustering-based protocol [2], and
� Ad hoc On-demand Distance Vector (AODV) – a
reactive routing protocol [3].
II. EXPERIMENTAL SETUP
A. Simulation settings
The various routing protocols were compared through the
simulation of wireless sensor networks with the OMNeT++
Discrete Event Simulation System [4]. In [5] it is stated that
traffic generation should be based on intended applications.
Since wireless sensor networks are usually designed to
handle sporadic or slowly changing events (such as
temperature and pressure variations) [6], it was assumed that
the application layer transmits information every 15 minutes.
In table 1 the settings used during the simulation are
displayed. For the radio model, a transmission distance of
1m was used, while the transmitter power was set at 2mW on
the mobility framework's physical layer implementation.
B. Calculating power consumption
To calculate power consumption, the simple radio model
introduced by [7] was used. It was initially used by the
authors to calculate the power consumption of the LEACH
protocol and was implemented in the OMNeT++ simulator
by [8].
A
TABLE I
SIMULATION SETTINGS
Setting Value
Transmission distance d=1m (for power calculations)
P max = 2mW (transmitter power)
Bit rate 10 kbps
PNRG used and seed Mersenne Twister
Seed automatically generated from
OMNeT++ simulator
Simulation package and version
number used
OMNeT++ Discrete Event
Simulation Package 3.2p1 with
Mobility Framework 2.0p2
Traffic type Data message sent once every 15
minutes
Mobility model Static, with random node placement
Comparing wireless sensor network routing
protocols
Gerrit Niezen, Gerhard P. Hancke, SMIEEE, Imre J. Rudas, FIEEE, and László Horváth, SMIEEE
1-4244-0987-X/07/$25.00 ©2007 IEEE.
2
Energy consumed during transmission (ETx) is calculated
with
2kdEkEE ampelecTx += (1)
where Eelec is the energy consumed by the radio transceiver,
k is the size of the message in bits, Eamp is the energy
consumed by the radio amplifier and d is the transmission
distance in meters.
It should be noted that even if the nodes are mobile, the
transmission distance is still constant, as the transmission
power of the radio transceiver does not change (except in the
case of LEACH where the transmission power is varied to
reach the base station node).
The energy consumed during message reception is
calculated by
kEE elecRx = (2)
where Eelec is the energy consumed by the radio transceiver
and k is the size of the message in bits. Energy consumption
during reception is only calculated when a message is
received, i.e. the radio transceiver only expends power
during message reception. This is usually not the case, as a
radio transceiver still expends a large amount of power when
in receive mode and not receiving messages. It is therefore
assumed that a time synchronization protocol is
implemented to switch off the radio transceiver when
messages are not being sent or received. The assumption is
also made that the radio channel is symmetric, i.e., the
energy consumed to transmit a message from node A to node
B is the same as to transmit a message from node B to node
A.
C. Experimental setup of flooding protocol
The flooding protocol can be seen as the most basic type
of routing protocol, where no routing tables are kept and
messages are broadcast across the network. It is also the
least energy efficient way to send messages across a wireless
network. The signal attenuation threshold for the simulation
was set at -110dBm and a carrier frequency of 868 MHz was
used.
D. Experimental setup of TinyOS 1.x multihop routing
TinyOS 1.x multihop routing is a shortest-path-first
algorithm with a single destination node (the sink node) and
active two-way link estimation. The TinyOS Surge
application is an implementation of this algorithm, with an
application layer that transmits sensor information from a
simulated Analog-to-Digital Converter (ADC) at
predetermined intervals.
A language translator called NesCT [9] was used to
convert the TinyOS source code (written in the TinyOS
language NesC) to OMNeT++ source code. NesCT has the
capability to allow the TinyOS source to be translated into
the format required by the Mobility Framework.
The Mobility Framework is a framework to support
wireless and mobile simulations in OMNeT++. It includes
basic components for the application layer, network layer,
NIC (Network Interface Controller) or physical layer, MAC
(Media Access Control) layer and also includes components
for simulating mobility. For this study static nodes were used
and mobility was not implemented.
A simulation's playground size can be defined as the
simulated area in which the network is contained. A
playground size of 200 by 200 units specifies a rectangular
area in which nodes can have X and Y coordinates from zero
up to 200 units.
Static nodes with random node placement were used. The
Mersenne Twister pseudo-random number generator was
used to place the nodes, with the seed generated
automatically from the OMNeT++ simulator.
To ensure that the nodes will be close enough to one
another to be within transmission range, the playground
sizes were simulated as specified in table 2. If the nodes are
too close to one another, most of the time will be spent
contending for the available wireless spectrum, and the
nodes will find it difficult to actually transmit data.
For the simulations a distinction was made between
routing update messages and data messages. Routing update
messages were defined to have a size of 64 bits, while data
messages were defined to have a size of 105 bits. Nodes
were initialized with only 5mJ of energy to speed up the
simulation.
E. Experimental setup of LEACH
LEACH is a self-organizing, adaptive clustering protocol
that uses randomization to distribute the energy load evenly
among the sensors in the network. In LEACH, the nodes
organize themselves into local clusters, with one node acting
as the local base station or cluster head. If the cluster heads
were fixed throughout the system lifetime, as in conventional
clustering algorithms, the sensors chosen to be cluster heads
would die quickly, shortening the lifetime of the network
dramatically. Thus LEACH includes randomized rotation of
the cluster heads such that it rotates among the various
sensors in order to not drain the battery of a single sensor
[7]. As seen in figure 1, there is an initial set-up phase for
each round during which the cluster heads are chosen, and a
steady-state state during which each node is allocated a slot
for data communication.
LEACH uses a distributed algorithm to determine the
cluster heads during the set-up phase. When clusters are
created, each node n autonomously decides if it will be a
cluster head for the next round. The selection is made
stochastically, in that each node select a random number
between 0 and 1 and if the number is lower than a threshold
T(n), the node becomes a cluster head. T(n) is determined by
TABLE 2
PLAYGROUND SIZES
Number of nodes Size (x, y)
10 200, 200
50 450, 450
100 650, 650
250 1000, 1000
3
��
�
�
��
�
�
���
����
����
����
�−
=
prP
PnT
1mod1
)( (3)
for nodes that have not been cluster head in the last 1/P
rounds, otherwise T(n) is zero [10]. P is a predefined
number that determines the average number of cluster heads
during a round and r is the number of the current round.
SolarLEACH [10] is a solar-aware implementation of the
LEACH protocol. For this study the SolarLEACH
implementation was used with the solar option disabled, in
order to test the default distributed LEACH protocol. A
centralized version is also available in the implementation.
The SolarLEACH implementation is optimized for speed on
the OMNeT framework, but is very experimental and prone
to crashing. Due to its experimental nature it was only
possible to simulate network sizes up to 100 nodes.
F. Experimental setup of AODV
The TinyAODV stack implements a simplified version of
the Ad-Hoc On Demand Vector (AODV) routing algorithm
that is implemented in TinyOS. As with the LEACH
implementation, NesCT was used to convert the TinyOS
code into OMNeT code. It is a reactive algorithm, so it
builds routes on demand when desired by source nodes. It
builds routes using route-request/route-reply messages. A
source node desiring a route to the destination generates and
broadcasts a route request (RREQ) message across the
network. When the RREQ arrives at the destination or an
intermediate node with the path to the destination, a route
replay (RREP) message is generated and propagated along
the reverse path. The nodes propagating the RREP back to
the source add a route entry for the destination. It supports
many RFC features, but it takes into account the reduced
capabilities of the wireless sensor network platforms
operating on TinyOS.
The implementation of TinyAODV makes various
simplifications in order to implement the AODV protocol in
a very small footprint:
� RREP messages are only generated by the destination.
� Routes never expire.
� Only the hop count metric is used.
� No messages are generated to keep routes active
because routes never expire. Route errors are generated
when a data message can no longer be sent over the
path. This is detected using the TinyOS link level
acknowledgments.
Unfortunately the TinyAODV implementation by NesCT
only allows a network size of 4 nodes. This makes a test like
determining the number of active nodes in the network at
certain intervals redundant. For this report the average
number of messages sent in the network was simulated and
evaluated.
III. RESULTS
A. Time until the first node fails
The time until the first node fails (with the results for
TinyOS 1.x multihop routing) can be seen in figure 4. For a
small network of only 10 nodes, the first node dies just
before t = 60 minutes. This is a huge improvement compared
to the flooding protocol, where the first node in the network
dies after only 15 minutes, just after the first data packet has
been sent (see figure 2). It does get worse for larger network
sizes, where the first node dies just after 20 minutes. This is
due to the larger number of packets that have to be
forwarded in the network.
In the case of LEACH (seen in figure 3) the time until the
first node fails is critical, as it is a cluster-based protocol and
the node that fails will most probably be a cluster head.
Unfortunately, for a network size of 100 nodes, the first
node already fails after 13 minutes, even before the first data
packet has been sent. This is due to the large amount of
messages required during the initial setup period, during
which the cluster heads are chosen.
Both TinyOS 1.x multihop routing and LEACH perform
about 3 times better than the flooding protocol. While the
performance of these two routing protocols is similar with
regards to the first node failing, the TinyOS algorithm
performs better for larger network sizes. The cluster heads in
LEACH fail earlier since they have to forward more data
than the regular nodes in the network and due to the extra
initial setup packets required during each round.
B. Average remaining energy in the network at selected
intervals
In figure 5 the average remaining energy of all the nodes in
the network are displayed at selected time intervals for the
flooding protocol. At t = 15 minutes, the first data packet is
sent and the power for each node is still close to maximum,
After 16 minutes, most of the nodes have no remaining
energy and just a few nodes have enough power for the
second data packet transmission.
In figure 6 the average remaining energy in the network at
selected intervals for TinyOS 1.x multihop routing can be
seen. Network sizes of both 10 and 50 nodes were simulated
to be able to compare the average remaining energy for
different network sizes. In both cases almost all the nodes
have died after about 60 minutes. Comparing this to figure 4
it can be seen that the first node died just before t = 60
minutes. This indicates that there is an almost even energy
consumption distribution across the network, where most of
the nodes die during the same time interval (from t = 60 to
t = 75 minutes).
Fig. 1. LEACH operations (From [10])
4
The average remaining energy for 10 nodes is linear for
the selected intervals, while the remaining energy for 50
nodes can almost be fitted to an exponential curve.
To determine the average remaining energy in the network
at selected intervals for LEACH as shown in figure 7, a
network size of 50 nodes were used. There is a small linear
decrease as time progresses, which can be accounted for
when considering the power requirements of every setup
period during each of the intervals.
While the flooding protocol has almost no remaining
energy after the first round of data messages at t = 15 min,
the TinyOS algorithm tends to drain its energy after about 60
minutes.
In this instance the LEACH protocol performs much
better, with the average remaining energy at t = 75 min still
at around 75%.
C. Time until the sink is unreachable, due to all of its
neighbours failing
In the case of the flooding protocol, the sink node
becomes unreachable after just 15 minutes. For the TinyOS
1.x multihop routing protocol, the different network sizes
does not seem to have an effect on the time until the sink is
unreachable, which is around 75 minutes. The results were
the same for network sizes of 50, 100 and 250 nodes.
For the LEACH protocol, such a test does not make sense,
since this will be the instant when all the nodes have died.
Because all the nodes are within range of the base station
(depending on their adjustable transmission range), the
cluster heads will be seen as sink neighbours. With rotating
cluster heads, all the nodes in the network should be
regarded as sink neighbours.
0
1000000
2000000
3000000
4000000
5000000
6000000
15 16 30
Time interval (min.)
Re
ma
inin
g e
ne
rgy (
mJ)
Fig. 5. Flooding: Average remaining energy at certain intervals (50 nodes)
10 50 100 250
0
250
500
750
1000
1250
1500
1750
2000
2250
2500
2750
3000
3250
3500
3750
Number of nodes
Tim
e (
s)
Fig. 4. TinyOS 1.x multihop routing: Time until the first node fails
15 30 45 60 75
0
500000
1000000
1500000
2000000
2500000
3000000
3500000
4000000
4500000
5000000
Time interval (min.)
Av
era
ge
re
ma
inin
g e
ne
rgy
(m
J)
Fig. 7. LEACH: Average remaining energy at certain intervals (50 nodes)
15 30 45 60 75
0
250000
500000
750000
1000000
1250000
1500000
1750000
2000000
2250000
2500000
2750000
3000000
3250000
3500000
3750000
4000000
10 nodes
50 nodes
Time interval (min.)
Ave
rage rem
ain
ing e
nerg
y (m
J)
Fig. 6. TinyOS 1.x multihop routing: Average remaining energy at certain
intervals
10 50 75 100
0
250
500
750
1000
1250
1500
1750
2000
2250
2500
2750
3000
3250
3500
3750
Number of nodes
Tim
e u
ntil firs
t no
de
fa
ils (
s)
Fig. 3. LEACH: Time until the first node fails
910
915
920
925
930
935
940
50 250 500 1000
Number of nodes
Tim
e (
s)
Fig. 2. Flooding: Time until the first node fails
5
D. Number of active nodes in the network at certain
intervals
As seen in figures 8 and 9, the LEACH protocol tends to
perform better than the TinyOS protocol with regards to the
number of active nodes in the network. LEACH has 90%
active nodes at t = 125 minutes, while the TinyOS algorithm
only manages t = 38 minutes. For 25% active nodes,
LEACH performs almost an order of magnitude better than
the TinyOS algorithm. It is interesting to note that TinyOS
multihop routing performs better for smaller size networks,
whereas LEACH actually performs better for larger
networks. For a network of 100 nodes, LEACH still has 25%
active nodes left after t = 417 minutes, compared to
t = 291 minutes for the network size of 50 nodes.
With the flooding protocol, almost no nodes remain active
after the first data packet is sent. All the other nodes’ energy
are expended just by forwarding data messages from other
nodes in the network.
E. Average number of messages sent in the network at
selected intervals
In figure 11 the average number of messages sent at selected
intervals with LEACH are shown, for a network size of 50
nodes. The linear increase indicates that while there is a
greater chance of the cluster heads dying earlier, the rest of
the nodes in the network continue to transmit data. This is
due to most of the nodes not being required to forward data
in the network, as this is handled by the cluster heads.
The average number of messages sent (i.e. number of
messages sent per node) is very high for the AODV routing
protocol compared to the other routing protocols, as seen in
figure 10. Using the 5mJ initial energy applied for the other
simulation models, the simulation only ran for a minute
before all nodes were drained of their energy. The network
size for the AODV simulation was set at 4 nodes (see
section II).
A single round of data messages sent with the flooding
protocol requires about 160 messages sent per node on
average. While the TinyOS algorithm sends more messages
initially (50 messages vs. 28 messages) than the LEACH
protocol, the LEACH protocol sends more messages in total
due to the cluster head setup periods during each round.
The difference however, is marginal: 150 messages sent by
the TinyOS algorithm vs. 160 messages sent by the LEACH
protocol. With the AODV protocol, almost 3500 messages
have been sent on average after only 15 minutes.
F. Average number of messages received by the sink at
selected intervals
A test to determine the average number of messages
received by the sink node (or destination node) at certain
intervals was also simulated. It is very interesting to note
that for the LEACH protocol there is a linear increase
indicating that most messages in the network has been
received by the sink node. In comparison, the TinyOS
algorithm has a much lower success ratio. After 15 minutes,
only 9 messages per node in the network has been received
by the sink node using the TinyOS algorithm, while about 23
messages per node has been received by the LEACH
protocol. At t = 60 minutes, the TinyOS sink has only
received 27 messages per node, while the LEACH sink has
already received 110 messages per node.
For the flooding protocol, more than 500 messages were
15 30 45 60 75
0
1020
30
40
50
60
70
80
90
100110
120
130
140
150
160
170
Time interval (min.)
Avera
ge n
um
ber
of m
essage s
ent
Fig. 11. LEACH: Average number of messages sent at certain intervals
15 30 45 60 75
0
2000
4000
6000
8000
10000
12000
14000
16000
18000
20000
Time interval (min.)
Avera
ge n
um
ber
of m
essages s
ent
Fig. 10. AODV: Average number of messages sent at certain intervals
90 75 50 25
0
2500
5000
7500
10000
12500
15000
17500
20000
22500
25000
27500
50 nodes
100 nodes
Number of active nodes in the network (%)
Tim
e (
s)
Fig. 9. LEACH: Number of active nodes at certain intervals
90 75 50 25
0
250
500
750
1000
1250
1500
1750
2000
2250
2500
2750
3000
50 nodes
100 nodes
Number of active nodes in network (%)
Tim
e (
s)
Fig. 8. TinyOS 1.x multihop routing: Number of active nodes at certain
intervals
6
received by the sink node after the first packet data
transmission. This means that for every node in the network
that sent a message, more than 9 duplicates were received by
the sink node. Since most of the nodes between the sink and
the outer edges of the network died after the first data packet
transmission, none of the data messages sent during the
second interval was received by the sink node.
IV. CONCLUSION
While allocating only 5mJ of energy to each node at
startup is a bit unrealistic, it shows the tremendous amount
of energy expended for even one data transmission interval
in the network when using a flooding protocol.
While the forwarding rules are simple, their performance
in terms of sent packets, or delay, is very poor. These
shortcomings are due to ignoring the network's topology.
Simulation results for the flooding protocol were validated
against the original OMNeT++ simulations done by [8].
The playground size (i.e. the size of the area in which the
nodes are placed) has a large effect on the outcome of the
simulation. If the nodes are distributed randomly, the
playground size has to be small enough so that enough nodes
can communicate with one another. It should not be so small
so that the nodes are constantly in contention for the
available radio spectrum, in which case they will not be able
to communicate if the radio channels are not available.
It should be noted that the credibility of the presented
results depend on the quality of the software used to
implement the protocols.
Experiments with the TinyOS 1.x multihop routing
protocol suggest that the network takes a long time to
converge, even for a small number of nodes. The topology
only starts to build after one or two minutes. By default, the
module sends a route update message once every 10 seconds
and re-computes after 50 seconds (i.e., 5 route update
messages are sent) [11].
LEACH makes some assumptions about both the sender
nodes and the underlying network, e.g., assuming that all
sensor nodes can adapt their transmission range and that
energy consumption during transmission scales exactly with
distance [10].
It is also assumed that every sensor node will be able to
reach the base station if it increases its transmission range. In
a typical wireless sensor network this is not the case.
Since AODV was originally developed for wireless
networks such as Wi-Fi, it does not conform to the power
requirements of wireless senor networks. While it can be
implemented in a wireless sensor network setting
(TinyAODV runs on any node that employs TinyOS), the
routing protocol will require serious adjustments and fine
tuning to minimize its power requirements. The average
number of messages sent in the network was much higher
than any of the other protocols, including the flooding
protocol.
Selecting a routing protocol to use in a wireless sensor
network is dependent on various factors like the network
lifetime, success rate and the number of nodes in the
network. The protocols evaluated in this paper performed
better in some of the criteria than others, but none of the
protocols were able to fulfil all of the stated criteria. The
TinyOS 1.x multihop routing protocol performed better than
the Low-Energy Adaptive Clustering Hierarchy (LEACH)
protocol for larger network sizes, whereas the LEACH
protocol had a better success ratio for the number of
messages received by the sink node. LEACH had a longer
network lifetime and average remaining energy, but the first
node failed earlier than in a TinyOS 1.x multihop routing
network.
To select a routing protocol for a wireless sensor network,
attention must be paid to the type of environment the
network is going to be deployed in, the Quality of Service
(QoS) required with regards to the sensed data and the size
of the network. The capabilities of the physical sensor
nodes, such as if the transmission distance can be scaled,
should also be considered.
Trying to adapt traditional wireless MANET (Mobile Ad-
hoc Network) protocols that were not originally designed
with the energy requirements of wireless sensor networks in
mind, does not seem feasible after evaluating a routing
protocol like Ad-hoc On-demand Distance Vector (AODV).
REFERENCES
[1] G. Niezen, “Realization of a self-organizing wireless sensor network,”
Final year project report, Pretoria: Department of Electrical,
Electronic and Computer Engineering, University of Pretoria, 2005.
[2] W.B. Heinzelman, A.P. Chandrakasan and H. Balakrishnan, “An
application-specific protocol architecture for wireless microsensor
networks,” IEEE Trans. on Wireless Communications, Vol. 1, Issue
4, pp. 660 – 670, Oct. 2002.
[3] C. Gomez, P. Salvatella, O. Alonso and J. Paradells, “Adapting
AODV for IEEE 802.15.4 mesh networks: Theoretical discussion and
performance evaluation in a real environment,” Proceedings of the
2006 International Symposium on a World of Wireless, Mobile and
Multimedia Networks, pp. 159 – 170, 2006.
[4] OMNeT++ Discrete Event Simulation System, 2006. [Online].
Available: http://www.omnetpp.org. Last accessed: 27 February
2006.
[5] T.R. Andel and A. Yasinsac, “On the credibility of MANET
simulations,” IEEE Computer, vol. 39, no. 7, pp. 48-54, July 2006
[6] E. Farella, A. Pieracci, D. Brunelli, L. Benini, B. Riccó and A.
Acquiviva, “Design and implementation of WiMoCa node for a body
area wireless sensor network,” Proceedings of the 2005 Systems
Communications, pp. 342-247, 2005.
[7] W. Heinzelman, A. Chandrakasan and H. Balakrishnan, “Energy-
Efficient Communication Protocol for Wireless Microsensor
Networks,” in Proceedings of the 33rd Hawaii International
Conference on System Sciences (HICSS), Hawaii, USA, pp. 1–10,
2000.
[8] C.J. Leuschner, “The design of a simple energy efficient routing
protocol to improve wireless sensor network lifetime,” Master's
Dissertation, Pretoria: Department of Electrical, Electronic and
Computer Engineering, University of Pretoria, 2005.
[9] NesCT: A language translator, 2006. [Online]. Available:
http://nesct.sourceforge.net. Last accessed: 14 November 2006.
[10] T. Voigt, H. Ritter, J. Schiller, A. Dunkels and J. Alonso, “Solar-
aware clustering in wireless sensor networks,” Proceedings of the
Ninth IEEE Symposium on Computers and Communications, June
2004.
[11] University of California Berkeley (2003, Sept.). Multihop routing,
TinyOS Documentation. [Online] Available:
http://www.tinyos.net/tinyos-1.x/doc/multihop/multihop_routing.html
Copyright Information
© 2007 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists,
or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.
top related