SECURING ROUTE DISCOVERY IN MAODV FOR

WIRELESS SENSOR NETWORKS

R.Shyamala*, Dr.S.Valli**
* Lecturer, Department of Computer Science and Engineering,
University College of Engineering, Tindivanam.
vasuchaaru@yahoo.com
** Assitant Professor, Department of Computer Science and Engineering,
Anna University, Chennai-25.
valli@annauniv.edu

ABSTRACT
The deployment of sensor networks for security and safety related environments
requires securing communication primitives such as broadcast, multicast and
point to point communication. Recent research shows that multicast provides
high energy saving in IP supported wireless sensor networks (WSN). In this
work, we investigate how to secure route discovery of the Multicast Ad-hoc on
Demand Distance Vector (MAODV) protocol for WSNs. For the ad-hoc
networks ARIADNE, SEAD, ARAN are some of the solutions, which cannot be
directly applied to energy constrained WSNs. Here, we propose a secure route
discovery of MAODV based on TESLA and one-way hash function. We have
simulated our work using NS-2. The performance of the secured MAODV and
the unsecured MAODV is compared.
Keywords MAODV, TESLA, Multicast, packet delivery ratio.

1 INTRODUCTION addressing in sensor nodes in a 4G-environment.

Wireless sensor networks [1] (WSN) consist
of a large set of multi-functional, low cost,
wirelessly networked sensor nodes. These sensor
nodes have control components and
communication functionality. Sensor nodes co-
operate with each other and are deployed in
environment monitoring, habitat monitoring,
healthcare, home automation, traffic control and
industrial system automation. Recent work [2]
[26][25] shows that rather than broadcast,
multicast in sensor network saves power. Among
various routing protocols [11] MAODV has a
very good performance.
For the application of MAODV, a platform
that supports IP functionality in WSNs is
required. Since sensor networks have power
consumption restriction, it is too complex to
apply the full TCP/IP protocol stack with IPV6
functionality to them. The authors [8][25]
describe a mechanism, which enables IP
The IETE group has also created,
LOWPANWG, which addresses IPV6
functionality for Personnel Area Networks
(PAN) including WSNs. The SICS research
group developed a new microprocessor, a WSN-
oriented operating system called Contiki [7],
which describes IP connectivity. The authors
[25] developed a test bed with IP and multicast
support in WSNs and concluded that it is feasible
to apply source specific multicast to WSNs.
In sensor networks, adverse nodes can freely
join the network, listen to and/or interfere with
network traffic, which leads to network failures.
So, it is necessary to design a security
mechanism that can prevent attacks by insiders
or outsiders for the tree based routing protocol,
namely MAODV.
2 RELATED WORK

UbiCC Journal, Volume 4, Number 3, August 2009 775

 Recently, several works have addressed
securing unicast routing protocols for ad-hoc
networks. ARIADNE [15], Secure Efficient Ad
hoc Distance vector (SEAD) [14], Authenticated
Routing for Ad hoc Networks (ARAN) [18],
Secure Ad hoc On-demand Distance Vector
(SAODV)[9], and Byzantine-Resilient Secure
Multicast Routing in Multi-hop Wireless
Networks (BSMR) [6] are the works, which
secure routing protocol.
ARIADNE [15] is based on Dynamic
Source Routing (DSR); it describes end-to-end
security for ad-hoc network routing. It makes use
of the message authentication code (MAC) to
authenticate routing table entries. It requires
clock synchronization in the network since the
security of DSR is based on TESLA. SEAD [14]
secures the Destination-Sequenced Distance-
Vector (DSDV) routing protocol and provides
authentication-using TESLA. It requires a shared
secret key between each pair of nodes. ARAN
[18] uses limited time certificates. So, it requires
a trusted certificate authority. This protocol
increases latency and discovers optimal shortest
paths. SAODV [9] combines digital signature
and hash chain and gives a secure Ad hoc On-
demand Distance Vector (AODV). It splits the
message into mutable and non-mutable fields.
Cryptographic signatures are used to authenticate
non-mutable fields. A One-way hash chain is
created for every route discovery process to
secure a hop count field, a mutable field of the
AODV message. This protocol requires a key
management mechanism. In any on-demand
routing protocol, route discovery plays an
important role. So, we consider how to secure
route discovery with minimal cryptographic
primitives, such as hash function and symmetric
encryption for wireless sensor networks.
The rest of the paper is organized as follows;
section 3 describes the network model and
system assumption used in the implementation.
Section 4 describes how to secure route
discovery of MAODV. Simulation results are
given in section 5 and section 6 concludes the
paper and suggests future work.
3 NETWORK MODEL AND SYSTEM
ASSUMPTION
We assume that a network has a central base
station and sensor nodes are densely deployed.
UbiCC Journal, Volume 4, Number 3, August 2009
The base station has abundant computation
resources. The base station has a private/public
key pair; the public key of the base station is
known to all the sensor nodes. For our system we
require a trusted key distribution center (KDC).
The base station acts as the KDC. It is
trustworthy and cannot be compromised. The
sensor nodes communicate using unreliable radio
links. The nodes in the sensor network are
resource constrained. Each node has a unique ID.
The nodes communicate with each other by
multihops. Since we use the TESLA-based
certificate for secure route discovery, all the
nodes have loosely synchronized clocks. The
clock difference between any two nodes does not
exceed the error rate (). All the nodes know the
value of . The time synchronization is
maintained by the hardware. The network links
are bi-directional.
We assume that an attacker attempts to
tamper with some links to reduce routing
information to its neighbor. An intruder can jam
outgoing packets. An attacker may be a
compromised node. If so, it will make use of all
the cryptographic keys and it may cooperate with
other attackers. We make no assumption on the
number of intruders, their location and their radio
range.
3.1 Tesla
Perring et al [23] present an efficient source
authentication technique called TESLA. It uses
pure symmetric cryptographic function and
ensures asymmetric property. TESLA divides
time into n equal intervals. Each n is assigned
a corresponding key Kn. The sender appends
MAC to the data generated at time interval n,
using the secret key Kn. The receiver simply
buffers the packets. After some d time slot, the
sender discloses the corresponding key seed Sn.
Using a public one way function F, the key Kn
can be derived from Sn.
To create a key seed chain the sender
chooses a terminal seed St and generates St-1
using a one-way function F. Thus, F (St) St-1,
F(St-1) St-2, F(St-2) St-3, F(St-3) . S0. For
key generation the key seed chain is used in the
reverse order (i.e. it starts from S0). Therefore,
F (Sn) Kn . Once the user receives a TESLA
seed Sn , he guarantees the authenticity by
checking F(Sn ) Sn-1. The authenticating key Kn
is generated using the one way hash function F.
776
 In our approach, TESLA is used in creating
group membership and node membership
certificate, which supports source authentication
in the MAODV secure route discovery.
4 SECURE MAODV
The Multicast Ad-hoc On Demand Distance
Vector (MAODV) routing protocol [27]
constructs a shared multicast tree, which
connects the group members. In addition, the
MAODV helps the group members to get
connected to the multicast tree through the
forwarding nodes. Members can join or leave the
group at any time. One of the group members is
the Group Leader. It initiates a route request at
first and initializes the group sequence to one.
The Group Leader is responsible for maintaining
the multicast sequence number. At regular
intervals it generates Group Hello (GH)
messages across the network to maintain the
multicast sequence number. The multicast
sequence number is used to check the freshness
of the multicast group.
The Wireless Sensor Network [2] is
deployed in a hostile environment. The
communication and deployment mode of WSNs
makes it insecure. Sensor networks consist of
resource constrained devices, implementing a
security mechanism. Thus, our proposed
authentication framework has the following
objectives
An unauthorized node should not be able to
participate in the MAODV routing.
Non-Group member node should not be able
to act as a group member.
Non-tree node should not be able to
impersonate a tree node.
To achieve the above goals, this work
proposes an authentication mechanism in which
the sensor nodes and base station need to have
necessary credentials to participate in the
MAODV protocol. All the four types of nodes
are used in the implementation. The nodes can be
A Group Member
A Group Leader from one among the Group
Members.
A Multicast Tree Member
A Non-tree Member
UbiCC Journal, Volume 4, Number 3, August 2009
The given group certificate and node
certificate are the elements of the authentication
frame work;
4.1 Group Certificate
Every group member has the privilege to
initiate a route request to join a multicast tree. It
has a Group Membership Certificate, which
justifies that it belongs to a particular multicast
group. To reduce the communication overhead
Group Group Life SIGN Group Public
ID Private Key Time Key(.)
2 Bytes 2 Bytes 2 Byte 2 Byte
Figure 1: Group Membership Certificate
in WSNs, we assume that a node can belong to
only one group. The format of the group
membership certificate [28] is shown in Fig. 1. It
contains the group ID, Group Private Key,
Lifetime of the certificate and the Group Public
Key used for signing the certificate.
4.2 Node Certificate
All the sensor nodes, whether a group
member or non-group member in the network
have a certificate called the node certificate. This
certificate is issued by a trusted certificate
authority (CA). In WSNs, the base station acts as
a certification authority. The format of the node
certificate is shown in Fig 2. Only nodes
possessing node certificates are eligible to
participate in routing. The base station
pre-distributes the node certificate off line to all
the sensor nodes in the network, before
deployment. All the nodes know the public key
of the Certificate Authority (CA). Thus, there is
no need to contact the CA for verification of a
node.
Node Node Life SIGN Nodes
ID Private Key Time (.)
Public Key
2 Bytes 2 Bytes 2 Byte 2 Byte
Figure 2: Node Membership Certificate
4.3 Group Leader
The Group Leader broadcasts the Group
Hello (GH) packets to all the valid group
members. The previous credentials of the group
leader are used to authenticate the GH messages.
777
 Join Request ID destination Group Source Node Start SIGN source private
Req ID group Membership Cert Certificate Time (ts) key (.)

Figure 3: Route Request Packet

Route Request ID ID Group Destination SIGN destination E Source private key

Repl ID group source sequence Node certificate private key () ( Dest ID, Tree
y node number key)

Figure 4: Route Reply Packet

Request In Hop Out Hop Life time

ID Node Node
k
Figure 5: Request table

4.4 Multicast tree Member

When a non-member joins the Multicast
tree, a shared tree is constructed if it is needed. J2
The Group Leader is the root of the Multicast 1

tree. It generates and securely distributes the tree

key to the entire Multicast tree members. A node
that has the valid tree key will reply the route
request.
4.5 Secure Route Discovery
Secure route discovery has two stages. At
first, a source node broadcasts the route request
and then it receives a route reply. The format of
the RREQ Message is given in Fig 3. RREQ has
seven fields;
RREQ: (Join Req , Request ID, ID destination group ,
Group Cert, Source Node Certificate, Start
Time, SIGN source private key (.) )
The request ID is used to check the freshness of
the request. The entire packet is signed using the
source private key. A node initiates the Route
Request Message [RREQ] in two situations;
Case i - If a group member i wants to join a
multicast group, then it prepares the RREQ
packet and broadcasts it to all its one hop
neighbors. If the receiver is a multicast tree node,
then it applies validation of the source algorithm
and sends a reply to the sender by checking its
routing table. The routing table contains the
control information of the destination. If the
receiver is a non-multicast tree node, then it
forwards the request by replacing the outer
signature with its own signature and forwards the
request to the neighbors. The nodes of the tree
J1
i
Network link
Reply route
Multicast tree node
Forwarding node
Node wanting to join the Multicast
tree node
Figure 6: Secure Route Discovery in MAODV
maintain a dynamic request table. The format of
the request table is shown in Fig 5.
Case ii - if a group member i wants to send
data to a destination group by creating the
multicast tree with valid group members of that
session, then it prepares the RREQ and replaces
the Join Request field by creating a multicast tree
field and the rest of the process is the same as in
Fig 7.

UbiCC Journal, Volume 4, Number 3, August 2009 778

 RREQ : (Create Tree Request, Request ID, ID
destination group , Group Cert, Source Node Certificate,
Start Time, SIGN source private key (.) ).
If a node i does not receive a RREP message
then it rebroadcasts the request m times. Then,
the node i declares itself as the group leader by
sending Group Hello Packets to all the group
members.
4.6 Working of Secure Route Discovery
If a node i wants to join a multicast tree,
the node will broadcast the route request packet
to all its one hop neighbors. The non-group
member forwarding the RREQ is the forwarding
node. The RREQ has two signatures. The
signature of the source node certificate is called
the inner signature. The entire RREQ packet is
signed by the forwarding node and it is called the
outer signature.
Algorithm: Validation of the Source Node
// tr denotes the time when the RREQ is received
// ts denotes the issue time of the RREQ
// D- propagation delay
1. Assume node k receives a RREQ at tr .
2. if ts +D<tr then
3. Discard the RREQ
4. else
5. if ( forwarding node is a trusted node) then
6. Buffer the RREQ packet and store
forward node ID in request table.
7. Wait (for group authenticating key to be
disclosed.)
8. if (source node i has a valid group
member certificate) then
9. Send the RREP packet with the following
details;
10. Append the tree key and reply node ID
11. Encrypt with the source node public key.
12. else
13. Discard the RREQ
14. end if
15. else
16. Report the unauthorized node to CA.
17. endif
18. endif
If a forwarding node j1 gets the RREQ,
then its checks the inner signature and stores the
UbiCC Journal, Volume 4, Number 3, August 2009
senders ID as in-hop ID in its request table. The
node j1 appends its certificate to the RREQ and
broadcasts it. Suppose a forwarding node j2gets
the RREQ packet from node j1then it checks
the outer signature, inner signature and
updates the request table. The node j2 adds its
certificate by replacing the certificate of node
j1 and broadcasts the RREQ. If a multicast tree
member k receives the RREQ then it removes
the outer and inner signature. The node k
checks the routing table and sends the RREP
packet. The format of the RREP is shown in
Fig 4. The working of secure route discovery is
given in Fig 7.
i * : [ RREQ ] ; // node i broadcasts RREQ.
j 1 : [ RREQ ] ; // node j receives the
RREQ.
// it checks inner signature and appends
// the forwarding Node Certificate.
j1 * : [ RREQ , Node Certificate of j1 ];
j2 : [ RREQ , Node Certificate of j1 ];
// validates & replaces certificate of node
j1.
j2 * : [ RREQ , Node Certificate of j2 ];
k : Executes validation of the source node
algorithm and sends RREP packet.
k j2 : [ RREP ]
j2 : [ RREP ];increments the hop count;
j2 j1 : [ RREP , Node Certificate j2 ] ;
j1 : [ RREP , Node Certificate j1 ] ;
j1 i : [ RREP , Node Certificate ji ] ;
i : // validates inner signature. Checks the
//group sequence no. updates multicast
// tree table, and request table
Figure 7: RREQ initiated by node i and its
subsequent actions to establish a secure route.
5 NETWORK PERFORMANCE
The network simulator NS-2
(http://www.isi.edu/nanam/ns/) has been used in
evaluating the performance of the secure route
discovery. Figure 8 shows the topology of the
simulation. Table 1 gives the simulation
parameters and Table 2 gives the default
MAODV parameters.
The simulated scenario consists of a network
with 30 nodes and two multicast groups A and B
with 10 members each. All the group members
779
 join the multicast group at the beginning of the and these values are compared with the MAODV
simulation leading to the construction of the values [25].

Table 2: Default MAODV Parameters

Parameters Values
Number of Allowed Hello Loss 3
Group Hello Interval 5 secs
Hello Interval 1 secs
Lifetime of Route Table Entries 3 secs
Max. No. of RREQ Retransmissions 3
Max Time to Wait for a RREP 5 secs

5.1 Performance Metrics

Figure 8 : Topology of the Simulated Wireless
Sensor network
multicast tree. The field ID is used in identifying
the nodes. The sensor with ID zero is the base
station, which is responsible for the distribution
of certificates. The base station plays the role of
the central TESLA certificate authority (CA).
Table 2 lists the default values of the MAODV
parameters used in the simulation. The node and
group certificates in our simulation use a 512 bit
public key and 16-byte signature as in [15].
Table 1: Simulation Environment Parameters
The packet delivery ratio, packet overhead,
average delay and average energy in the network
are used as the metrics for evaluating the
performance.
a) Packet Delivery Ratio (PDR) is defined as the
ratio of the total number of data packets received
by the multicast group members to the product of
the number of data packets sent and the number
of group members.
The analysis shows that PDR is 40% high
for secure MAODV, because RREQ message
collision takes place while broadcasting. The
certificate of the sender is appended along with
the message. So, the packet size increases.
b) Average delay in the network: In the
simulated environment group A is distributed
and group B is densely packed. So, the average
delay in the network is 15 % more for group A
when compared to group B. In real time scenario
the WSNs are densely packed and hence cause
less delay.

Parameters Values
Number of Nodes 30 1

Pause Time 50 sec 0.95 S- MAODV

Simulation Grid Size 500mX500m 0.9 MAODV
Radio Transmission Range 50 m 0.85
Packet_Send x 103

Transmitting power 0.175 mW 0.8

V Receiving power 0.145 mW 0.75

Sensing power 0.00000175 mW 0.7

V Idle power 0.0 mW 0.65

0.6
Initial energy 5.0 Joule
0.55

0.5
Each simulation was run for 100 seconds. 0.45
After 30 seconds, one group member (node 6) 50 100 150 200 250

joins the group securely. For each set of Time (ms)

experiments, 50 runs were performed. The Figure 8: Packet delivery ratio of Secure
average values are used in plotting the graphs MAODV and MAODV.

UbiCC Journal, Volume 4, Number 3, August 2009 780

 1.2

500 1.1

1
450 S- MAODV group A group B
0.9
400 MAODV

3
0.8

Average Energy x 10
350 0.7
Average Energy

300 0.6

250 0.5

0.4
200
0.3
150
0.2
100
0.1

50 0
50 100 150 200 250
0
Tim e (m s)
50 100 150 200 250
Time (ms)

Figure 11: Average delay for member join in

Figure 9: Energy analysis of Secure MAODV group A and B.
and MAODV.
6 CONCLUSION
c) Energy Analysis: The average energy of the
network is calculated as the sum of the energy of In this work, we have reduced the group
the sensor nodes divided by the number of nodes. membership and node membership certificate.
The simulation shows that the average energy We have introduced a request table, which stores
drops to 20% with an increase of 30 numbers of the next hop and previous hop IDs. We have also
nodes. reduced authentication overhead. All these
features are well-suited for low-power devices
such as sensor networks.
450
S- MAODV
In this work, we have applied a TESLA-
400 MAODV
based certificate to secure MAODV for low
350
power Wireless sensor networks. It is proven that
we can apply Secure MAODV, which has a
300
10 3 negligible impact on MAODV performance
250
gy x
Ener during the normal operation of the protocol.
200
age
Aver

150 Future Enhancement

100 The simulation study shows that the
50
TESLA-based Certificate with MAODV is
0 possible with wireless sensor networks. Further,
50 100 150 200 250
if we create a cluster-based multicast, the
Time (ms) performance will greatly improve. The tradeoff
between delay and overhead is a critical issue for
further study.
Figure 10: Average delay of Secure MAODV
and MAODV. REFERENCES

The disadvantage is that, it requires clock [1] I. Akyildiz W. Su, Y. Sankarasubramaniam

synchronization and the existence of a and E. Cayirci: A Survey on Sensor
private/public key pair between base station and Networks, IEEE Communications
sensor nodes. To authenticate the TESLA key for Magazine, Vol. 40, No. 8, pp. 102-116,
each node, a one-way hash chain has to be (2002).
maintained. TESLA keys are distributed to the [2] I. Akyildiz and I. Kasimoglu: Wireless
participating nodes via the offline key sensor and actor networks: research
distribution center.

UbiCC Journal, Volume 4, Number 3, August 2009 781

 challenges Ad Hoc Networks , Vol 2(4):
pp. 351-367, (2004).
[3] Chenyang Lu, Guoliang Xing, Octav
Chipara, Chien-Liang Fok, Sangeeta
Bhattacharya : A Spatiotemporal Query
Service for Mobile Users in Sensor
Networks, pp. 381-390, 25th IEEE
International Conference on Distributed
Computing Systems (ICDCS'05), pp. 381-
390(2005)
[4] Perrig, A., Szewczyk, R., Tygar, J. D., Wen,
V., and Culler, D. E: SPINS: security
protocols for sensor networks. Wirel. Netw.
8, 5 (Sep. 2002), pp 521-534 (2002).
[5] Lidong Zhou; Haas, Z.J: Securing ad hoc
networks, Network, IEEE, Vol 13, Issue 6,
pp 24 30(1999).
[6] F. Stajano and R. J. Anderson, The
resurrecting duckling: Security issues for ad-
hoc wireless networks, in Seventh
International Security Protocols Workshop,
Vol 19,No 21, pp. 172194 (1999).
[7] Contiki Operating System,
http://www.sics.se/~adam/contiki/, (2005).
[8] A. Dunkels, T. Voigt and J. Alonso. Making
TCP/IP Viable for Wireless Sensor
Networks. In Proceedings of the First
European Workshop on Wireless Sensor
Networks (EWSN'04), work-in-progress
session, Berlin, Germany, pp. (2004).
[9] Zapata, M. G.: Secure ad hoc on-demand
distance vector routing. SIGMOBILE Mob.
Comput. Commun. Rev. 6, 3 pp 106-107
(Jun. 2002).
[10] H. Luo, P. Zefros, J. Kong, S. Lu, and L.
Zhang, Self-securing ad hoc wireless
networks, in Seventh IEEE Symposium on
Computers and Communications (ISCC
02), (2002).
[11] S. Bhattacharyya, "An Overview of Source-
Specific Multicast", RFC3569, (2003).
[12] B. Dahill, B. N. Levine, E. Royer, and C.
Shields, A secure routing protocol for ad-
hoc networks, Electrical Engineering and
Computer Science, University of Michigan,
Tech. Rep. UM-CS-2001-037, August 2001.
[13] J. Kong, H. Luo, K. Xu, D. L. Gu, M. Gerla,
and S. Lu, Adaptive security for multi-layer
ad-hoc networks, Special Issue of Wireless
Communications and Mobile Computing,
Wiley Interscience Press,( 2002).
UbiCC Journal, Volume 4, Number 3, August 2009
[14] Y.-C. Hu, D. B. Johnson, and A. Perrig,
SEAD: Secure efficient distance vector
routing for mobile wireless ad hoc
networks, in Proceedings of the 4th IEEE
Workshop on Mobile Computing Systems
and Applications (WMCSA 2002), pp. 3
13(2002).
[15] Hu, Y., Perrig, A., and Johnson, D. B. 2005.
Ariadne: a secure on-demand routing
protocol for ad hoc networks. Wirel. Netw.
Vol 11, No 1-2 pp 21-38 (2005).
[16] S. Basagni, K. Herrin, E. Rosti, and D.
Bruschi, Secure pebblenets, in ACM
International Symposium on Mobile Ad Hoc
Networking and Computing, pp. 156
163(2001)
[17] P. Papadimitratos and Z. Haas, Secure
routing for mobile ad hoc networks, in SCS
Communication Networks and Distributed
Systems Modeling and Simulation
Conference (CNDS 2002), (2002).
[18] Sanzgiri, K., Dahill, B., Levine, B. N.,
Shields, C., and Belding-Royer, E. M.: A
Secure Routing Protocol for Ad Hoc
Networks. In Proceedings of the 10th IEEE
international Conference on Network
Protocols, pp 78-89(2002).
[19] S. Buchegger and J.-Y. L. Boudec, Nodes
bearing grudges: Towards routing security,
fairness, and robustness in mobile ad hoc
networks, in Proceedings of the Tenth
Euromicro Workshop on Parallel,
Distributed and Network-based Processing.
Canary Islands, Spain: IEEE Computer
Society, pp. 403410(2002)
[20] Zhu Yufang, Kunz T.: MAODV
Implementation for NS-2.26 (SCE-04-01).
Ottawa:Department of Systems and
Computing Engineering . Carleton
University, (2004).
[21] NS-2: http://www.isi.edu/nsnam/ns/
[22] SensorSim: NRL's Sensor Network
Extension to NS-2, Naval Research
Laboratory.
[23] A. Perrig, R. Canetti, J. Tygar, and D.
Song, The TESLA Broadcast
Authentication Protocol, RSA CryptoBytes,
5, 2002.
[24] YANG Mingxi, LI Layuan, FANG Yiwei.
Securing Multicast Route Discovery for
Mobile Ad Hoc Networks, Journal of
natural science,Vol.12, 189-192(2007).
782
 [25] Jorge S Silva, Tiago Camilo, Pedro Pinto,
Ricardo Ruivo, Andr Rodrigues, Filipa
Gaudncio, Fernando Boavida. Multicast
and IP Multicast support in Wireless Sensor
Networks, JOURNAL OF NETWORKS,
VOL. 3, NO. 3, pp. 19-26(2008).
[26] Camilo, T., S Silva, J.,Boavida, F., IPv6
in Wireless Sensor Networks, a New
Challenges, First International Workshop
on Convergence of Heterogeneous Wireless
Networks, Julho 2005.
[27] E. M. Royer and C. E. Perkins. Multicast
operation of the ad-hoc on-demand distance
vector routing protocol. In Fifth Annual
ACM/IEEE International Conference on
Mobile Computing and Networking,
Mobicom 99, pp. 207218 (1999).
[28] Bohge, M. and Trappe, W.: An
authentication framework for hierarchical ad
hoc sensor networks. In Proceedings of the
2nd ACM Workshop on Wireless Security,
pp ,79 87(2003).
[29] David A. Maltz, Josh Broch, Jorjeta
Jetcheva, and David B. Johnson. The Effects
of On-Demand Behavior in Routing
Protocols for Multi-Hop Wireless Ad Hoc
Networks. IEEE Journal on Selected Areas
in Communications, Vol. 17(8), pp. 1439
1453(1999).
[30] R. Szewczyk, E. Osterweil, J. Polastre, M.
Hamilton, A. Mainwaring, and D. Estrin.
Habitat monitoring with sensor networks.
Communications of the ACM, Special Issue:
Wireless sensor networks, Vol. 47(6), pp.
3440(2004).
[31] Lorincz, K., Malan, D. J., Fulford-Jones, T.
R., Nawoj, A., Clavel, A., Shnayder, V.,
Mainland, G., Welsh, M., and Moulton, S. :
Sensor Networks for Emergency Response:
Challenges and Opportunities. IEEE
Pervasive Computing,Vol 3, No 4, pp 16-
23(2004).

UbiCC Journal, Volume 4, Number 3, August 2009 783