2010 International Conference on Broadband, Wireless Computing, Communication and Applications
AntSens: An Ant Routing Protocol for Large Scale Wireless Sensor Networks M Goyal, W Xie, H Hosseini University of Wisconsin Milwaukee Milwaukee, WI, USA mukul,wxie,
[email protected]
Y Bashir Johnson Controls Inc. Milwaukee, WI, USA
[email protected]
nodes in the network. There are distance vector protocols [7]–[10] where a node exchanges routing information, including information regarding topology changes in its neighborhood, only with its immediate neighbors. Some of these protocols are proactive, i.e., the protocols maintain routes to destinations in anticipation that such routes would be used in future. Some of the protocols are reactive or on-demand where a route is discovered only when actually needed. The ROLL (routing over low-power and lossy networks) working group in Internet Engineering Task Force (IETF) is currently engaged in the design of RPL, a Routing Protocol for Lowpower and lossy networks. The working group has identified a set of necessary (although not sufficient) criteria to evaluate a routing protocol’s suitability for use in large scale wireless sensor networks [11]:
Abstract—Large scale wireless sensor networks, consisting of thousands of nodes spread over a large geographical area, are being planned for a number of monitoring and control applications. The individual nodes in such networks would be severely limited in their capabilities - they will have limited memory and CPU resources and would typically run on batteries. A suitable routing protocol for large wireless sensor networks should scale well with the size of the network in terms of the control packet, memory and processing overhead. Dynamic link/node characteristics, such as PHY/MAC loss rates and battery levels, in such networks require continuous monitoring of the quality of existing routes and frequent discovery of new routes. The routing protocol should allow distribution of traffic load through out the network to avoid artificial congestion, and hence high MAC level loss rates, in parts of the network. The existing routing protocols do not meet all the criteria mentioned above. Hence, we propose a new routing protocol meeting the criteria mentioned above. The proposed protocol, called AntSens, may be considered as belonging to the category of ant routing protocols that are based on the manner ants discover and remember the best routes to the food location.
•
I. I NTRODUCTION Wireless communication among sensor devices is increasingly replacing the existing wired technology in a wide range of monitoring and control applications. New monitoring and control applications, based on large scale wireless sensor networks, are being conceptualized [1]. The proposed networks would typically use a low power and low data rate MAC/PHY protocol such as IEEE 802.15.4 [2] and could consist of several thousand nodes spread over a large geographic area [3]. These nodes would be severely limited in their capabilities - they will have limited memory and CPU resources and would typically run on batteries. The sensor nodes would need to communicate with other nodes in the network that are not in their radio range. This makes it necessary for a large wireless network to operate a routing protocol that allows packets from a source node to reach a destination node over a multi-hop path through other nodes in the network. Routing protocols come in several flavors. There are link state routing protocols [4]–[6] that require each node to maintain knowledge of the current complete/partial network topology. Thus, a node may need to flood information regarding a topology change in its neighborhood to all the 978-0-7695-4236-2/10 $26.00 © 2010 IEEE DOI 10.1109/BWCCA.2010.46
•
•
41
Table scalability refers to whether the routing related information each node is required to maintain scales well with the size of the network. The routing related information should be in proportion to the number of destination nodes in the network, rather than the total number of nodes in the network or the number of nodes in the immediate neighborhood of a node. Loss response refers to the control packets generated following the loss of connectivity between two nodes. The loss response of the routing protocol should be limited. The routing protocol should not need to spread the information throughout the network. Control Cost refers to the packets sent and received by a node during the operation of the routing protocol (such as route discovery/maintenance). Packet transmission and reception is a costly operation in wireless sensor networks. Wireless sensor networks can typically support very low data rates (popular IEEE 802.15.4 MAC/PHY protocol supports maximum data rate of 250Kbps [2]). So, there is a desire to use this capacity for data packets rather than routing protocol’s control packets. Further, the nature of wireless communication mandates that, among all the nodes in each other’s radio range, only one node can transmit at a time. Finally, packet transmission as well as reception requires energy, which is a precious resource for wireless sensor nodes. The control cost of a node should be
bounded by the data rate. Moreover, the route discovery/maintenance operations should not require networkwide broadcast of control messages. Adhoc On-demand Distance Vector (AODV) [8] is a category of routing protocols that have many of the desirable features listed above. As its name suggests, AODV is an ondemand routing protocol, where routes are discovered when required. In AODV, the route discovery proceeds in the following manner. A source node broadcasts a Route Request. All the nodes, except the destination, receiving the request for the first time broadcast it further. The destination node sends a Route Reply for every Route Request it receives. The Route Reply travels back to the source node using the same route as taken by the corresponding Route Request to the destination. During its travel back to the source, the Route Reply accumulates the link costs over the route. On receiving the Route Reply carrying information regarding a particular route, the source may decide to use the route based on accumulated cost of the route. The Route Reply messages may be used to update the routing tables on the nodes they travel through or can be used by the source nodes to determine the complete routes to the destinations. AODV variants exist where the route discovery process is a little different. In these variants, the intermediate nodes can send a Route Reply on receiving a Route Request back to the source node if they already know a route to the destination. AODV routing automatically avoids loops if minimum cost routes are used. Popular Zigbee protocol suit [12] uses an AODVlike routing algorithm on top of IEEE 802.15.4 MAC/PHY layers. AODV is not a suitable routing protocol for large-scale wireless sensor networks since it does not meet the control cost criterion discussed above. AODV route discovery is based on network-wide broadcast of Route Request messages. In the worst case, each node in the network may need to transmit the Route Request. Thus, the message complexity of AODV’s route discovery is O(n), where n is the number of nodes in the network. The costly route discovery makes it difficult to continuously improve routes in face of changing network conditions. Further, there is no provision for monitoring the quality of existing routes. In the following, we present a routing algorithm that allows continuous discovery/monitoring of new/existing routes in a distributed fashion at a cost that is a configurable fraction of the data traffic load on the network. The proposed protocol also inherently supports traffic load distribution throughout the network if multiple high quality routes exist between sources and destinations. The Nature of the Proposed Protocol: The proposed protocol, henceforth referred to as AntSens, may be considered as belonging to the category of ant routing protocols [13]. Consider a group of ants continuously making trips between their nest and the location of food. As ants travel, they deposit a chemical, substance, pheromone, en route. The
concentration of pheromone along a route depends on the frequency of travels along that route. The ants follow the route emanating the strongest pheromone odor. Initially, an ant has no preference among multiple available routes as each smells the same and hence it takes each route with equal probability. However, after some time, the route with the shortest distance to the food location would emerge as the one with strongest odor since, in a given time interval, an ant can make more trips to the food location via this route than any other route. As ants start to use the shortest route in preference to other routes, the existing pheromone deposits along the other routes would slowly fade away and ultimately disappear. Routing protocols, based on ant routing approach, have been proposed for traditional wired networks [13], [14] as well as wireless mobile adhoc networks (MANETs) [15]– [18] that have very different requirements and constraints than wireless sensor networks. We refer the reader to [19] for a brief description of many of these protocols. Although a number of ant routing based algorithms have been proposed for wireless sensor networks as well [20]–[22], most of these algorithms focus on determining routes that take node battery levels in account so as to minimize the energy consumption and maximize the network life time. These algorithms mostly do not meet various scalability requirements mentioned earlier. Rather than incorporating the energy minimization policies within the routing protocol, we have focused on providing a simple and scalable routing solution that allows the sensor nodes to continuously discover the best quality routes for their packets. The proposed AntSens routing protocol allows the nodes to enforce any local energy conservation policy it may have. For example, a batterypowered node may refuse to forward packets originated at other nodes or periodically go to sleep. AntSens would automatically take the local node policies in account while determining the best quality routes available in the network. II. AntSens: T HE P ROPOSED ROUTING P ROTOCOL FOR L ARGE S CALE W IRELESS S ENSOR N ETWORKS The AntSens operation consists of three tasks: periodic neighborhood discovery, packet forwarding/reception and maintaining end-to-end reliability of reaching the destination(s). A. Neighborhood discovery A node periodically sends the heart-beat (or Hello) messages via 1-hop broadcast to let other nodes in its radio range know about its presence. If a node ocassionally goes to sleep to save energy, it sends a new hello message whenever it wakes up and mentions its awake duration in that message. If a node does not want to be used for packet forwarding, it need not send a Hello message. The heart-beat messages allow a node to dynamically keep track of its one-hop neighbors that are willing to forward packets and their awake
42
times. However, the protocol does not require a node to keep track of all its one-hop neighbors. Due to possible memory constraints, a node may want to keep track of only a subset (N ) of its one-hop neighbors.
receiving an ACK packet ack, originated by destination d, from a neighbor n, a node updates the rel value inside the ACK packet and its Rn,d value in the following manner: ack.rel =
B. Packet Forwarding and Reception
Rn,d
Let N represent the set of one-hop neighbors that are being tracked by a node s. Suppose node s needs to send packets, possibly originated at some other node, to a destination node d. For each node n ∈ N , node s maintains a metric Rn,d that represents the end-to-end reliability of forwarding a packet, going to destination d, to neighbor n. The maintenance of end-to-end reliability values are discussed in Section II-C. In the following discussion, we refer to an Rn,d value simply as R when the n and d parts are obvious from the context. If the destination of a packet is not directly reachable, the source/intermediate node forwards the packet to an awake and willing neighbor node. The neighbor to which a data packet is forwarded, hence forth referred to as a next-hop, is determined in a uniformly random fashion from neighbors with the highest R values. The set of awake and willing neighbors with the highest R values, henceforth referred to as maxRnbrs, is updated whenever R value is updated for a neighbor. A packet is not forwarded to the node from which it is received (the previous hop) or to the original source of the packet. Also, an intermediate node, on receiving a packet, increments the hop-count in the packet’s header and discards the packet if the hop count exceeds a certain threshold. Thus, AntSens inherently supports distributing the traffic load throughout the network when multiple high quality routes exist.
=
ack.rel × macSuccessRate
(1)
(1 − w) × Rn,d + w × ack.rel
(2)
where macSuccessRate is the current MAC-level success rate at the node and parameter w < 1 is a suitable constant (e.g. 0.2). The node then forwards the ACK packet to the node from which the corresponding ACKR packet was received. Thus, the ACK packets convey to a receiving node the current end-to-end reliability along the route taken by the corresponding ACKR packet originated/forwarded by the node. Note that the Rn,d values are maintained as exponentially weighted moving averages with weight w assigned to the current reliabilty. For an ACKR packet p it originates/forwards, the node needs to remember the packet’s signature, sig(p), consisting of the original source, the final destination, the sequence number of the packet as well as its previous and next hop nodes. The packet signatures allow the node to forward a received ACK to the neighbor from which the corresponding ACKR packet was received. The packet signatures also allow a node to determine if a received ACKR packet is a duplicate in which case it is discarded. Periodically, a node checks the current number of signatures it has for packets forwarded to a particular neighbor and deletes some of the old signatures if this number exceeds a threshold. Since an individual ACK packet carries the value of the current end-to-end reliability along the route taken by the corresponding ACKR packet, the loss of even a large fraction of ACKR and ACK packets can be tolerated as long as at least one ACK packet makes its way to the source node (of the ACKR packet) within a reasonable time period t (e.g. 10 minutes). However, if no ACK has been received in response to the ACKR packets forwarded to a neighbor n during time period t, a node updates the Rn,d value in the following manner:
C. Maintaining End-to-End Reliability of Reaching the Destination For a fraction of packets it originates, the source node solicits an end-to-end acknowledgement, hence forth simply referred to as ACK, from the final destination of the packet. Such packets are referred to as the ACK Request, or simply as ACKR, packets in the following discussion. The objective of the ACKR packets is to sample the current end-to-end reliability of reaching the destination via each neighbor node. To meet this objective, the source node forwards an ACKR packet to an awake and willing neighbor selected in a round-robin fashion. However, at subsequent hops, the ACKR packet get the same treatment as an ordinary data packet, i.e. it is forwarded to one of the neighbors currently in maxRnbrs set. On receiving an ACKR packet, the destination node generates an ACK in response and sends it back to the source node along the reverse of the route taken by the corresponding ACKR packet. The ACK packet maintains an end-to-end reliability value, rel, which is initialized to 1 at the destination node. On
Rn,d = (1 − w) × Rn,d
(3)
The update of Rn,d value also causes the node to update the maxRnbrs set. Note that, to minimize the probability of their loss, the ACKR/ACK packets should use the highest reliability service (e.g. acknowledged transmission) provided by the MAC layer. III. P ROPERTIES OF THE P ROPOSED ROUTING P ROTOCOL Memory Requirement: Let D be the set of all the destination nodes the node needs to send packets to. Let η and θ represent the cardinality of sets N and D respectively. Note that a node need not track all its 1-hop neighbors. Hence, η would have an upper limit. A node needs to maintain the following information in memory:
43
The set N of 1-hop neighbors that the node tracks. Rn,d , ∀n ∈ N, ∀d ∈ D, which require O(ηθ) memory. • N ⊂ N {sig(p), n}, where sig(p) is the signature of an ACKR • packet p forwarded to node n that has not yet been ACKed. Since a node restricts the number of packet signatures per neighbor to a maximum value, the total memory requirement for storing packet signatures is O(η). Thus, the memory requirement of the routing protocol is O(ηθ) or O(θ) as η can be considered a constant. Clearly, the AntSens protocol meets the Table Scalability requirement described in Section I. On the Routing Loops: Routing loops are possible, although not persistent, in AntSens. Consider the situation where node A forwards a packet to node B. Node B forwards the packet to node C, which in turn chooses to forward the packet back to node A. The limit on hop count ensures that the packet will be ultimately dropped if it stays in the loop. Further, each node needs to keep signatures for the ACKR packets that it has forwarded further but that have not yet been ACKed. The node uses the packet signatures to drop any duplicate ACKR packets presumably travelling in a loop. Thus, node A would ultimately reduce the R value for node B. Hence, any routing loops will not be permanent in nature. Use of Broadcast/Multicast: AntSens avoids the use of broadcast/multicast for data packet forwarding or route monitoring/discovery. This is because the packets forwarded via broadcast/multicast typically can not avail of MAClevel acknowledgements and hence become susceptible to loss via MAC-level collisions or PHY-level noise. Moreover, network-wide broadcast of packets, e.g. for route discovery, have scalability problems. The protocol still uses the 1-hop broadcast for the hello messages. Multiplicative Accumulation of Link Reliabilities: Traditional routing protocols such as AODV use an additive accumulation of link costs to determine the end-to-end route cost. Additive accumulation is not suitable for metrics such as success rate (or reliability). Calculation of the end-to-end reliability of a route requires multiplication of the reliabilities of the constituent links. AntSens inherently supports multiplicative accumulation of link reliabilities.
the native IEEE 802.15.4 module in NS2 simulator and represents an accurate implementation of the IEEE 802.15.4 specification. The simulations were performed on a network of 101 nodes distributed in a 200m × 200m region. The node locations were determined one-by-one in the following manner. The x and y coordinates of a new location were determined in a uniform random fashion in range {0m, 200m} under the constraint that the minimum distance between a new location and an existing location should not be less than 10m or larger than 30m. This was done to ensure that a new location is always in the radio range of atleast one existing location. The radio range for each node in these simulations was a circle with radius 31.45m. Thus, we ensured that there were no partitions in the simulated topology. The simulations had 100 nodes originating packets at Poisson-distributed rates, 1 packet per second (1 pps) and 1 packet per 5 seconds (0.2 pps), for a common destination located close to the center of the 200m × 200m grid. Figure 1(a) gives a visual representation of the simulated network topology. Figure 1(b) shows the number of nodes having a given number of neighbors in their radio range. Figure 1(c) shows the number of nodes with a given minimum hop distance from the destination. The simulations assumed a noise-free PHY operation where a packet transmission by a node is correctly received by all nodes in the radio range and by no node outside the radio range. The becaonless IEEE 802.15.4 MAC layer required acknowledgement for every packet transmission except that of multicast hello packets. In a simulation, the packet losses may occur only due to channel access failures or collision failures at the IEEE 802.15.4 MAC layer [2]. The simulations assumed that the IEEE 802.15.4 MAC layer in each node has already completed association with some other node in the network before the start of the simulation. Each packet transmitted by a node was 133 byte in size, including the IEEE 802.15.4 MAC/PHY headers and the AntSens header, the maximum allowed in IEEE 802.15.4 PHY operation. In the simulation results reported in this section, we have used the end-to-end loss rate during a particular time period as the performance metric. This time period was set to 30 and 60 minutes respectively for 1pps and 0.2pps simulations. The end-to-end loss rate was used as the performance metric since the AntSens protocol has been designed for use in large scale low-power low-rate wireless networks where improving the reliability of receiving remote sensor data is the most important requirement. However, suitable modifications can be done to the protocol to meet the needs of other applications where timely delivery of data takes precedence over reliability. Such modifications and their evaluation are out-of-scope for the current paper. The 1 pps simulations reported in this section ran for 6.5 hours each while the 0.2 pps simulations ran for 20 hours
• •
IV. S IMULATIONS BASED P ERFORMANCE E VALUATION In this section, we present results of a simulation based performance evaluation of the AntSens protocol. These simulations were performed using an implementation of the AntSens protocol in the NS2 simulator [23]. In these simulations, each simulated node used AntSens as the routing protocol and beaconless IEEE 802.15.4 operating with default configuration in 2.4 GHz range as the MAC/PHY layer protocol. The IEEE 802.15.4 module used in these simulations is an extensively improved version [24] of
44
Number of Nodes
y-axis (in meters)
150 100 50
16
30
14
25
Number of Nodes
src dest
200
12 10 8 6 4 2
0 0
50 100 150 x-axis (in meters)
200
(a) The Topology
15 10 5 0
2 3 4 5 6 7 8 9 10 11 12 Number of Neighbors in Radio Range
(b) Connectivity in the Topology Figure 1.
20
0 1 2 3 4 5 6 7 Min. Hop Distance of the Node from Dest. Node
(c) Min. Hops from Destination
Characteristics of the 100 Node Topology Used in Simulations
each. The simulation graphs show nodes grouped according to their minimum hop distance from the destination. Figure 1(c) shows the number of nodes with a given minimum hop distance from the destination. The nodes in the simulations used 0.2 as the value of w, the weight of ”current” reliability in Eq. 2 used to update R values. Also, a node updates the R value of a neighbor n as per Eq. 3 when it sends an ACKR packet to n and no ACK has been received from n in response to previous ACKR packets sent to it over last 10 minutes. The set of neighbors used for packet forwarding was updated with each update in an R value and consisted of neighbors with R value more than 90% of the maximum R value.
to converge to the steady state depends on the network topology, the traffic loads and the ACKR frequency and can be of the order of several hours as Figure 2 shows. Figures 3(a) and 3(b) show how the end-to-end loss rates at the steady state change with change in ACKR frequency in 1 pps and 0.2 pps simulations respectively. Note that the change in ACKR frequency from 1% to 5% causes the end-to-end loss rates to increase, the increase being much more noticable in case of 0.2 pps simulations. Figures 3(c) and 3(d) show the MAC-level loss rates at each node calculated over the same time duration as the end-toend loss rates shown in Figures 3(a) and 3(b) respectively. Figures 3(c) and 3(d) show that the MAC-level loss rates are indeed higher for 5% ACKR frequency than for 1% ACKR frequency. The corresponding increase in end-to-end loss rates are more noticable in case of 0.2 pps simulations than for 1 pps simulations because of low loss rate values prevalent in 0.2 pps simulations. A small increase in low MAC-level loss rates causes much larger increase in endto-end loss rates than the same increase in large MAC-level loss rates. Clearly, the ACKR frequency to use depends on the prevalent traffic load on the network. Lightly loaded networks should use a lower ACKR frequency than heavily loaded ones. It is possible to dynamically adjust the ACKR frequency based on prevalent MAC-level loss rate at the node, which is an indicator of prevalent traffic load in the node’s neighborhood.
A. The impact of the frequency of ACKR packets on convergence Each node requests an end-to-end ACK from the destination on a fraction of packets it originates. An ACK conveys to the receiving node the current end-to-end reliability along the route followed by the corresponding ACKR packet. Requiring a higher percentage of the originated packets to be ACKR packets would speed up the network’s convergence to steady state as the nodes receive more frequent reliability updates. However, the ACKs generated by the destination in response to ACKR packets it receives also increase the traffic load on the network, which causes the MAC-level loss rates at individual nodes and hence end-to-end loss rates for the nodes to increase. Thus, deciding what fraction of the originated packets should be used as ACKR packets requires a careful tradeoff between the needs to quickly converge to steady state and to minimize the increase in loss rates due to ACK packets. Figure 2 shows the impact of ACKR frequency on the speed of convergence to steady state in 1 pps and 0.2 pps simulations. Requiring 5% of the originated packets to be ACKR allows the network to converge to steady state in about 1 hour and 4 hours respectively in 1 pps and 0.2 pps simulations. Reducing the fraction of ACKR packets to 1% slows down the convergence speed almost proportionately to 3 hours and 13 hours respectively for 1 pps and 0.2 pps simulations. Clearly, the time required by the protocol
V. C ONCLUSION Routing in large scale wireless networks of highly contrained devices and links with highly variable reliability characteristics presents unique design challenges. There is a need to continuously monitor and update the routes being used. Flooding based route discovery, used in popular AODV-based protocols, is not suitable for this purpose. In this paper, we presented AntSens, an ant routing protocol designed for large scale wireless sensor networks. This protocol is able to continuously adjust the routes being used in response to changes in the reliability levels of the links in the network. The frequency with which the reliability of the existing routes is monitored affects the protocol’s con-
45
E2E Loss Rate Over 30 min
E2E Loss Rate Over 30 min
0.7 0.65 0.6 0.55 0.5 0.45 0.4 0.35 0.3 0.25 0.2
after 60min after 390min 11
29
52 Nodes
82
E2E Loss Rate Over 1 Hour
E2E Loss Rate Over 1 Hour
0.3 0.25 0.2 0.15 0.1 after 4 hours after 20 hours 29
52 Nodes
82
98
0.3 0.2
after 180min after 390min
0.1
0.18 0.16
29
52 Nodes
82
98
82
98
after 13 hours after 20 hours
0.14 0.12 0.1 0.08 0.06 0.04 0.02 11
(c) 5% ACKR, 0.2 pps Simulations Figure 2.
0.4
(b) 1% ACKR, 1 pps Simulations
0.4
11
0.5
11
0.35
0
0.6
98
(a) 5% ACKR, 1 pps Simulations
0.05
0.7
29
52 Nodes
(d) 1% ACKR, 0.2 pps Simulations
Impact of the frequency of ACKR packets on the convergence of end-to-end loss rates to their steady state values
vergence to the optimal set of routes. Infrequent monitoring will lead to slow convergence, but extra traffic load due to too much monitoring may adversely impact the reliability of links around popular destinations. Thus, the monitoring frequency needs to be selected carefully. Antsens holds great promise as a highly scalable solution to the routing problem in large unreliable wireless networks. We are currently engaged in further evaluation of the protocol via simulations and test-bed experiments to enhance its performance.
[5] T. Clausen and P. Jacquet, “Optimized Link State Routing Protocol (OLSR),” IETF, Request For Comments 3626, Oct. 2003. [6] R. Ogier, F. Templin, and M. Lewis, “Topology Dissemination based on Reverse-Path Forwarding (TBRPF),” IETF, Request For Comments 3684, Feb. 2004. [7] G. Malkin, “RIP Version 2,” IETF, Request For Comments 2453, Nov. 1998. [8] C. Perkins, E. Belding-Royer, and S. Das, “Ad hoc OnDemand Distance Vector (AODV) Routing,” IETF, Request For Comments 3561, Jul. 2003.
R EFERENCES [1] A. Wheeler, “Commercial applications of wireless sensor networks using zigbee,” IEEE Communications Magazine, vol. 45, no. 4, pp. 70–77, April 2007.
[9] I. Chakeres and C. Perkins, “Dynamic MANET On-demand (DYMO) Routing,” IETF, Internet-Draft draft-ietf-manetdymo-14, Jun. 2008, work in progress.
[2] “Part 15.4: Wireless MAC and PHY layer specifications for low-rate wireless personal area networks,” IEEE Std 802.15.42006, 2006.
[10] D. Johnson, Y. Hu, and D. Maltz, “The Dynamic Source Routing Protocol (DSR) for Mobile Adhoc Networks for IPv4,” IETF, Request For Comments 4728, Feb. 2007.
[3] M. Dohler, T. Watteyne, T. Winter, and D. Barthel, “Routing Requirements for Urban Low-Power and Lossy Networks,” IETF, Request For Comments 5548, May 2009.
[11] P. Levis, A. Tavakoli, and S. Dawson-Haggerty, “Overview of Existing Routing Protocols for Low Power and Lossy Networks,” Internet Engineering Task Force, Internet-Draft draftietf-roll-protocols-survey-07, Apr. 2009, work in progress.
[4] J. Moy, “OSPF Version 2,” IETF, Request For Comments 2328, Apr. 1998.
46
E2E Loss Rate After 20 Hours
E2E Loss Rate After 390 minutes
0.65 0.6 0.55 0.5 0.45 0.4 0.35 0.3 0.25 0.2 0.15
1% ACKR 5% ACKR 11
29
52 Nodes
82
52 Nodes
82
98
(c) 5% ACKR versus 1% ACKR: 1 pps Simulations Figure 3.
0.15 0.1 0.05 0 29
52 Nodes
82
98
(b) 5% ACKR versus 1% ACKR: 0.2 pps Simulations
MAC Loss Rate After 20 Hours
MAC Loss Rate After 390 minutes
29
0.2
11
1% ACKR 5% ACKR
11
1% ACKR 0.25 5% ACKR
98
(a) 5% ACKR versus 1% ACKR: 1 pps Simulations
0.5 0.45 0.4 0.35 0.3 0.25 0.2 0.15 0.1 0.05 0
0.3
0.07
1% ACKR 5% ACKR
0.06 0.05 0.04 0.03 0.02 0.01 0 11
29
52 Nodes
82
98
(d) 5% ACKR versus 1% ACKR: 0.2 pps Simulations
Impact of the frequency of ACKR packets on the end-to-end loss rate for each node
[18] O. Hussein and T. Saadawi, “Ant routing algorithm for mobile ad-hoc networks (ARAMA),” in In Proceedings of IEEE International Performance, Computing and Communications Conference 2003, 2003, pp. 281–290.
[12] Zigbee Alliance, “Zigbee specification,” Dec. 2006. [Online]. Available: http://www.zigbee.org [13] G. D. Caro and M. Dorigo, “AntNet: Distributed stigmergetic control for communications networks,” Journal of Artificial Intelligence Research, vol. 9, pp. 317–365, Dec. 1998.
[19] H. Ren and M. Q.-H. Meng, “Biologically inspired approaches for wireless sensor networks,” in In Proceedings of IEEE International Conference on Mechatronics and Automation, Jun. 2006.
[14] R. Schoonderwoerd, O. Holland, J. Bruten, and L. Rothkrantz, “Ant-based load balancing in telecommunications networks,” Adaptive Behavior, vol. 2, pp. 169–207, 1996.
[20] S. Bashyal and G. Venayagamoorthy, “Real-time collaborative routing algorithm for wireless sensor network longevity,” in In Proceedings of IEEE International Symposium on Inteliigent Control Part of IEEE Multi-conference on Systems and Control 2008, 2008.
[15] G. D. Caro, F. Ducatelle, and L. M. Gambardella, “AntHocNet: an ant-based hybrid routing algorithm for mobile ad hoc networks,” in In Proceedings of Parallel Problem Solving from Nature (PPSN) VIII. Springer-Verlag, 2004, pp. 461– 470.
[21] S. Peng, S. Yang, S. Gregori, and F. Tian, “An adaptive QoS and energy-aware routing algorithm for wireless sensor networks,” in In Proceedings of IEEE International Conference on Information and Automation 2008, Jun. 2008.
[16] J. Baras and H. Mehta, “A probabilistic emergent routing algorithm for mobile ad hoc networks,” in In Proceedings of WiOpt03: Modeling and Optimization in Mobile, Ad Hoc and Wireless Networks, 2003.
[22] R. Aghaei, M. Rahman, W. Gueaieb, and A. Saddik, “Ant colony-based reinforcement learning algorithm for routing in wireless sensor networks,” in In Proceedings of Instrumentation and Measurement Technology Conference - IMTC 2007, May 2007.
[17] M. Gunes, U. Sorges, and I. Bouazizi, “ARA - the ant-colony based routing algorithm for MANETs,” in In Proceedings of ICPP 2002 Workshop on Ad Hoc Networks, 2002.
47
[23] S. McCanne and S. Floyd, “ns network simulator.” [Online]. Available: http://www.isi.edu/nsnam/ns/ [24] M. Goyal, “Zigbee/IEEE 802.15.4 module for NS2 simulator,” 2008. [Online]. Available: http://www.cs.uwm. edu/∼mukul/wpan.html
48
