國
立
交
通
大
學
資訊科學與工程研究所
碩
士
論
文
為 ZigBee 無線感測網路所設計之一利用機率性隨播之
兼具省電及耗電平衡之群播協定
An Energy-Efficient, Load-Balanced Multicast Protocol with
Probabilistic Anycast for ZigBee Wireless Sensor Networks
研 究 生：盧奕丞
為 ZigBee 無線感測網路所設計之一利用機率性隨播之
兼具省電及耗電平衡之群播協定
An Energy-Efficient, Load-Balanced Multicast Protocol with
Probabilistic Anycast for ZigBee Wireless Sensor Networks
研 究 生：盧奕丞 Student：Yi-Chen Lu
指導教授：曾煜棋 Advisor：Yu-Chee Tseng
國 立 交 通 大 學
資 訊 科 學 與 工 程 研 究 所
碩 士 論 文
A ThesisSubmitted to Institutes of Computer Science and Engineering College of Computer Science
National Chiao Tung University in partial Fulfillment of the Requirements
for the Degree of Master
in
Computer Science
為 ZigBee 無線感測網路所設計之一利用機率性隨播
之兼具省電及耗電平衡之群播協定
學生: 盧奕丞 指導教授: 曾煜棋 教授 國立交通大學資訊科學與工程研究所碩士班 摘 要 在無線感測網路中，由於感測節點的電力資源有限，因此省電的群播協定是 一個重要的議題。而在 ZigBee 規範中，因為群播服務是由週期性的區域氾濫式 傳播所達成，所以造成了非常高的成本消耗。另一方面，雖然有許多關於群播的 轉傳節點選擇演算法被提出，但這些方法之中，資料傳輸路徑是固定的，導致耗 電不平衡甚至單節點失效問題。除此之外，在網路拓樸會改變的情況下，必須要 負擔額外的維護成本。在本篇研究中，我們提出一個利用機率性隨播之符合 ZigBee 規範的群播協定，目的是要減少電量消耗並且平衡耗電以延長網路壽命 並且避免單節點失效問題。機率性隨播根據涵蓋率成本比例來選擇轉傳節點。涵 蓋率成本比例為可到達之目的成員節點個數與電量消耗成本之折衷權衡，可幫助 在最小化電量消耗的同時，最大化可到達之目的成員節點個數。我們更進一步利 用在選擇轉傳節點時考量各節點之剩餘電量，而在我們的設計中引進耗電平衡的 概念。當網路的拓樸改變且各節點之電量不斷消耗的同時，轉傳節點的集合會不 斷隨之改變以適應這些情況。模擬的結果顯示，我們所設計之群播協定可比 ZigBee 規範提供更長的網路壽命，並且在電量消耗、延遲及可靠性上都更加出 色。 關鍵字: IEEE 802.15.4、群播、無線感測網路、ZigBee。An Energy-Efficient, Load-Balanced Multicast Protocol with
Probabilistic Anycast for ZigBee Wireless Sensor Networks
Student: Yi-Chen Lu
Advisor: Prof. Yu-Chee Tseng
Department of Computer Science
National Chiao-Tung University
ABSTRACT
In wireless sensor networks (WSNs), energy-efficient multicast is a critical issue due to the limited power resource of sensor nodes. In ZigBee, multicast is accomplished by periodical regional flooding, resulting in extremely high cost. On the other hand, although some works have proposed relay node selection algorithms for multicast, the data delivery paths are fixed, leading to unfair or even single-node-failure problem. Moreover, extra cost is required in the face of topology changes. In this paper, we propose a ZigBee multicast routing protocol with probabilistic anycast, which aims for less energy consumption and load balance in order to prolong the network lifetime and avoid single-node failure. The probabilistic anycast mechanism chooses relay nodes based on a coverage-over-cost ratio, which is a tradeoff between the number of destination nodes that can be reached and the energy cost to reach them. This helps maximize the number of reachable member nodes while minimize the energy consumption. We further introduce the idea of load balance to our design by considering each node’s residual energy when choosing relay nodes. As the network topology changes and the energy of the nodes deplete, the set of forwarders for multicast can adapt to such conditions. Simulation results show that our protocol provides longer network lifetime and outperforms ZigBee in energy consumption, latency, and reliability.
誌謝
非常感謝曾煜棋教授兩年來不辭辛勞的指導，使我在學業上獲益良多。也感 謝實驗室的各位學長姐以及學弟妹，不管是在課業上或是生活上都受到各位相當 大的幫助和照顧。感謝爸媽辛苦工作，作為我追求學問的強力支援。更要感謝林 正中教授給予我進入交大資訊工程與研究所就讀的機會。最後，特別感謝潘孟鉉 學長、蔡佳宏學長以及徐子文學長，謝謝你們給予我的各種指導與鼓勵，我會珍 惜這段與你們一同研究及打球的時光，這將會是我人生最美好的回憶之一。 在此向大家獻上我誠摯地謝意跟祝福 盧奕丞 謹識於 國立交通大學資訊科學與工程研究所碩士班 中華民國九十八年八月Contents
Abstract (in Chinese) i
Abstract (in English) ii
誌謝 i i i Contents i v List of Figures v 1 Introduction 1 2 Preliminaries 4 2.1 ZigBee Multicasting ………... 4
2.2 Related Multicasting Solutions ………. 6
3 Design of Multicast Protocol 9
3.1 Table Maintenance Module ……… … 10
3.2 Multicasting Module ……… 11
3.2.1 Backoff Mechanism ………..……… 12
3.2.2 Packet Overhearing Mechanism ……… 14
4 Simulation and Experiment Results 1 6
5 Conclusions 2 6
List of Figures
1 Comparison in number of packets against ZigBee ………. 17
2 Comparison in latency against ZigBee ………... 18
3 Impact of group size on number of packets ………... 20
4 Impact of group size on latency ………. 20
5 Time elapsed when first node death occurs ……… 21
6 The number of multicast accomplished when first node death occurs ………... 21
7 Residual energy of each node after 8000 multicasts in ZigBee ………. 22
8 Residual energy of each node after 8000 multicasts in our protocol …………. 22
1 Introduction
The rapid progress of wireless communication and MEMS technology have made wireless sensor networks (WSNs) possible. A WSN is composed of many inexpensive wireless sen-sor nodes, each being powered by batteries. These nodes are capable of collecting, stor-ing, processing environmental information, and communicating with neighbor nodes. A lot of research works have been dedicated to WSNs, such as routing [6][8], self-organization [11][23], deployment [7][15][28], and localization [5][22]. Applications of WSNs include emergency guiding [14][26], light control [18][19], and environment monitoring [24].
Recently, many WSNs industries have adopted ZigBee [1] as their communication proto-col. ZigBee adopts the physical (PHY) and the medium access control (MAC) layers defined by IEEE 802.15.4 [10] and extends to network, application, and security services. Under this scope, some works have addressed the data collection [25] and network formation issues [17]. In this work, we are interested in the design of energy-efficient multicast in a ZigBee WSN. Multicast is a common communication operation. In ZigBee, a multicast message can be delivered in member mode or non-member mode. If the source node is a non-member, the multicast packet is in the non-member mode and it will be unicast to any member node. After reaching a member node in non-member mode or when being initiated by a member
node, the multicast packet is in member mode. When owning a multicast packet, a member node will conduct regional flooding periodically to deliver the packet. While the purpose is to conquer the reliability problem that normally associates with wireless broadcast [16], serious collision and bandwidth waste will be incurred.
On the other hand, although many works have proposed relay node selection algorithms for multicast, these schemes are too complicated to be applied in WSNs due to the limited resources of sensor nodes. In addition, the proposed works fail to achieve energy efficiency and load balance at the same time because fixed relay routes may lead to unfair or even single-node-failure problem.
In this paper, we present a ZigBee multicast routing protocol with probabilistic anycast, which aims for less energy consumption and load balance in order to prolong the network lifetime and avoid single-node failure. The probabilistic anycast mechanism chooses relay nodes based on a coverage-over-cost ratio, which is a tradeoff between the number of des-tination nodes that can be reached and the energy cost to reach them. This helps maximize the number of reachable member nodes while minimize the energy consumption. We further introduce the idea of load balance to our design by considering each node’s residual energy when choosing relay nodes. As the network topology changes and the energy of the nodes
deplete, our multicast protocol can adapt to such conditions.
The rest of the paper is organized as follows. In Section 2, ZigBee multicasting and other related multicasting solutions are studied. We then present our design in Section 3. Simulation and experiment results are shown in Section 4. Finally, the concluding remarks are given in Section 5.
2 Preliminaries
2.1 ZigBee Multicasting
Depending on whether the multicast source is a group member or not, there are two modes in ZigBee multicast: member mode and non-member mode. If the multicast source is a member, the multicast packet will be delivered in member mode; otherwise, it will be de-livered in non-member mode. ZigBee assumes that group members are physically separated by no more than MaxNonMemberRadius hops, which is a system parameter. There is no acknowledgment mechanism in ZigBee multicast. In order to resolve the unreliability prob-lem, each forwarder needs to rebroadcast, on receipt of a multicast packet, the packet three times blindly. This is known as regional flooding. The rebroacast is bounded by MaxNon-MemberRadius hops from any member. When a node in the region receives the packet, it first checks if it has already received the packet. The packet is rebroadcast if the node has never received the packet, and the rebroadcast will be done three times. If the receiver is a member, the packet will be flooded to the new region bounded by MaxNonMemberRadius hops from the member receiver. Note that if there are overlapped region, the packet will not be delivered redundantly because the nodes located in the overlapped region will know that whether they have received the packet before.
In non-member mode, the multicast source has to check whether it knows any route to any of the members. If the source does not know such route, it has to perform the route discovery procedure, which is similar to AODV. An RREQ command will be flooded to the whole network until a member replies an RREP back to the source. Then the source unicasts the multicast packet to the member using the path built by the route discovery procedure. When the member receives the packet, the packet will be delivered in member mode instead. However, there are several drawbacks in the above procedures. First, the energy cost is extremely high due to the above costly route discovery and regional flooding. Second, without any acknowledgement mechanism, the multicast communication in ZigBee is unre-liable. The multicast communication in ZigBee relies on blind retransmissions to provide reliability of packet delivery; nevertheless, the blind retransmissions increase the probabil-ity of packet collision. In fact, regional flooding further worsen the situation. As we have mentioned, while conducting regional flooding, there are many non-member nodes which are not supposed to participate in the packet propagation. These unnecessary relay nodes are performing not only meaningless broadcast transmissions but also worthless retransmissions of the multicast packet, both of which cause much higher probability of packet collision and decrease the reliability of packet delivery.
2.2 Related Multicasting Solutions
Many research works have been devoted to proposing the energy-efficient multicast routing protocols, but many of them cannot be easily applied to WSNs due to the limited resources of sensor nodes. These proposed schemes can be generally categorized into three major types: overlay multicast [3][4], geographic multicast [12][20][21], and relay-selection multicast [2][13][27].
Overlay multicast builds a virtual topology spanning all member nodes of a multicast group. The routing information is kept in the member nodes, and the multicast operations are performed only by the member nodes. The underlying routing can be implemented by unicast [8][9][29][30] or broadcast. PAST-DM [4] applies unicast as the underlying routing protocol, but it leads to excessive energy consumption and redundant transmissions. Al-though AOM [3] applies broadcast to eliminate redundant transmissions, it brings about packet header overhead. Besides, the tree-construction cost of overlay multicast is expensive because for different source nodes, they have to build their own overlay trees.
Geographic multicast [12][20][21] assumes that the geographical location information of all nodes is available and each node locally chooses the forwarders according to the location information. But the assumption is impractical for WSNs because the power resource of
sensor nodes is limited, and the energy cost for embedding GPS devices in sensor nodes is too expensive. Also, the packet header overhead still exists in geographic multicast. Besides, geographic multicast suffers from the cost of face routing because it may reach a void zone which has no neighbors providing any progress toward the destinations.
Relay-selection multicast [2][13][27] tries to construct a approximate steiner tree which delivers the multicast packet with minimum cost. MIP [27] is pruned from BIP which builds a minimum-cost spanning tree based on Prim’s algorithm and takes into account the wireless broadcast advantage. uCast [2], NJT and TJT [13] propose minimum set cover heuristics to solve the tree construction problem. But these approaches are centralized, which means the global network information must be available. Also, the computing complexity is high because the algorithms try to find the optimal solution among all possible cases. The source-tree construction cost is high because different source nodes have to build their own data delivery trees.
In all the three types of multicast designs, extra cost is required in the face of topology changes. Also, the data delivery paths are fixed. This may lead to unfair or even single-node-failure problem. The nodes on the data delivery path are always in charge of forwarding the multicast packets and thus quickly exhaust their energy. When a node exhausts its energy,
new route maintenance could cost a lost. More seriously, this could result in network parti-tion.
3 Design of Multicast Protocol
Our multicast protocol is featured by energy efficiency and load balance using probabilistic anycast. It prolongs the network lifetime and avoids the single-node-failure problem. Our protocol also chooses relay nodes to forward the multicast packets; however, the selection of relay nodes and the corresponding reachable members are determined by the receivers of the multicast packets, rather than senders. Each node maintains two tables: 1) neighbor
table (NT) and 2) multicast member table (MMT). The NT of node v keeps track of the
direct neighbors of v; each entry has the format (i, Ei), where i is a neighbor of v and Ei is
node i’s residual energy. The MMT of a node v keeps track of the multicast members that are within MaxNonMemberRadius hops from node v, where MaxNonMemberRadius is a system parameter. Each entry in the MMT has the format (m, hm), where m is a member
node and hmis the hop distance from node v to m.
Our protocol consists of three modules: Table Maintenance, Multicasting, and Topology
Maintenance. The Table Maintenance module utilizes member nodes’ periodical broadcast
to maintain their NTs and MMTs. The Multicasting module transmits packets by a proba-bilistic anycast scheme. Member nodes perform regional multicasts, and the nodes inside the region compete for relaying the packet by using the coverage-over-cost metric, which
measures the number of reachable members and the estimated energy cost to reach them. A random backoff mechanism is designed to support anycast. The anycast results in multi-path routing effects, which achieve load balance and higher delivery ratio. Also, an overhearing mechanism is designed to ensure reliability and inhibit redundant packet relays.
3.1 Table Maintenance Module
We enforce member nodes to transmit HELLO packets periodically to maintain all the nodes’ NTs and MMTs. HELLOs are transmitted by regional flooding. However, since we assume a static WSN (but with some link fluctuations), the frequency to send HELLOs can be reduced to after these two tables are stabilized.
A HELLO packet has the format: HELLO(rly, org, Erly, h, Nmax), where rly is the
node which relays this packet, org is the originator of this packet, Erly carries rly’s residual
energy, h indicates the hop count that this HELLO has traveled so far, and Nmax is the
maximum number of members within MaxNonMemberRadius hops from any node in the network. Note that each node also maintains the largest Nmax that it has learned so far.
Initially, a node’s Nmaxis the size of its own MMT.
The maintenance of NTs is intuitive, so we will discuss the maintenance of MMTs below. Each member node org periodically initiates a HELLO(org, org, Eorg, 0, Nmax). When a
node v receives a HELLO(rly, org, Erly, h, Nmax), it compares the received Nmaxagainst its
local Nmax. If the former is larger, v will update its local Nmax. Then v checks if there exists
an entry whose id is org in its MMT. If not, v will insert an entry (org, h + 1) to its MMT. Otherwise, assume the found entry to be (org, h0). If h0 > h + 1, v will update this entry as
(org, h + 1). Finally, if h + 1 < MaxNonMemberRadius, v will rebroadcast a HELLO(v,
org, Ev, h + 1, Nmax).
3.2 Multicasting Module
Our protocol does not distinguish member mode from non-member mode. When a node (member or non-member) wants to initiate a multicast packet, it performs a regional multi-cast. The size of a region is controlled by the parameter MaxNonMemberRadius. Any node which receives the multicast packet can extend the region by adding those members inside its region. Relay of a multicast packet is done by competition based on our probabilistic anycast scheme. The scheme is energy-aware and is able to balance the nodes’ responsibility to relay packets. It also achieves a multi-path effect to improve the delivery ratio. A differ-entiated backoff mechanism is designed for the competition behavior. Also, an overhearing mechanism is included to remove redundant relays.
node which initiates/relays the packet, M = (m1, m2, . . . , mr) is the list of member nodes
to which node v intends to relay the packet, H = (h1, h2, . . . , hr) is a list such that hi is the
hop distance from v to mi, i = 1. . . r, Eavg is the average residual energy of v’s neighbors,
seq is an unique sequence number to identify this multicast packet, and msg is the multicast
message. For an initiator, M and H are copied directly from v’s MMT. For a relay node, M and H will be recalculated as described in Section 3.2.2. Below, we discuss how a node u processes a received MCAST(v, M, H, Eavg, seq, msg). In the special case of initiating a
new multicast packet, we will regard u = v. Section 3.2.1 discusses the backoff mechanism and Section 3.2.2 discusses the packet forwarding mechanism.
3.2.1 Backoff Mechanism
When u receives from v a MCAST(v, M, H, Eavg, seq, msg), u first verifies if this is the
first time that the pair (seq, msg) is received. If so, u does the following (otherwise, the following steps are ignored):
1. From M, u tries to compute new lists M0 and H0 as follows. For each entry (m, h) in
u’s MMT, we do the following:
m to M0 and add h to H0.
2. Let δ = P
h∈H0
h. We define the coverage-over-cost ratio of u as:
r(u) = |M0|
δ − |M0| + 1 (1)
. Note that the numerator is the number of members that u may reach, and the denomi-nator is the worst case hops to reach these members (i.e., the total unicast cost to reach each node in M0minus the saving from u’s broadcast, |M0| − 1).
3. Then u will compete with its neighbors to retransmit the MCAST by a backoff scheme. The backoff counter is computed via the above coverage-over-cost ratio. Fisrt, we identify the maximum and the minimum values of r(u) as follows:
rmax = Nmax, (2)
rmin =
1
MaxNonMemberRadius. (3)
Eq. (2) represents the best case where there are Nmax reachable members that can be
reached in one hop. On the contrary, Eq. (3) represents the worst case where there is only one member within MaxNonMemberRadius hops. Node u will randomly pick a backoff value tb from the range [0, T ] such that
where Tmaxis a constant time interval, Euis u’s residual energy and Eavg is the average
residual energy of u’s neighbors.
Thus, the above design allows a node with a larger coverage-over-cost ratio and/or with more energy (relative to its neighbors) to compete for rebroadcasting the MCAST with a higher priority (i.e., a shorter backoff timer). Then u sets up a backoff counter tb, after which
it will multicast a MCAST(u, M0, H0, E
avg, seq, msg) to its neighbors.
3.2.2 Packet Overhearing Mechanism
After starting its backoff counter tb, we enforce u to overhear other nodes’ multicast for two
purposes: (i) to reduce packet transmission and (ii) to ensure reliability of the multicast. Recall the packet MCAST(u, M0, H0, E
avg, seq, msg) to be sent by u. The first one is to
further reduce the set M0. Once u resends its multicast, it will keep on overhearing others’
multicasting to ensure that all members are covered.
Overhearing before tb: After starting its backoff counter tb, u will check if the same
multicast packet is sent by any other relay node before tb expires. If so, it checks its
desti-nation set and removes from M0 and H0 each member that has been covered by that packet.
When tb times out, if M0is not empty, u sends out MCAST(u, M0, H0, Eavg, seq, msg).
a period of time twait to confirm that all member nodes in set M0 are covered by some relay
nodes. Similar to the previous step, whenever a packet is overheard, u checks its destination set and removes from M0each member that appears in that set. If M0is not empty when t
wait
expires, u will rebroadcast the MCAST packet again with updated M0 and H0 containing
those members that have not been covered. On the contrary, if M0 is empty, this means that
the MCAST is successfully forwarded by u’s neighbors. Because such confirmation process will be applied by all the relay nodes during the propagation of the MCAST, our scheme can achieve high reliability.
4 Simulation and Experiment Results
We design several experiments with C language to evaluate the performance of our multicast protocol. First, we build a ZigBee network. The network resides in a 35 × 35 m2square
re-gion, where hundreds of sensor nodes are randomly deployed. The full energy of each node is approximately 100 joules. The transmission power, transmission rate, and transmission power of each node are set to 6 meters, 250 kbps, and 50 mW , respectively. The multicast group members are randomly selected among the nodes in the network. Besides, since Zig-Bee defines that the multicast group members are physically separated by a hop distance of no more than MaxNonMemberRadius, we set the parameter to 5 in our simulation experi-ments. We adopt IEEE 802.15.4 MAC protocol with unslotted CSMA/CA algorithm as our MAC protocol. Next, we demonstrates our protocol performance against ZigBee multicast in each experiment.
Fig. 1 shows the impact of the network size on the total number of packets incurred by our protocol and ZigBee. The network size varies from 100 to 500 nodes and we evaluate the total number of packets transmitted by our protocol against ZigBee. We randomly select 10 nodes as multicast members. In each multicasting, we will randomly choose one node as multicast source among these 10 members. Apparently, our protocol produces much fewer
0 100 200 300 400 500 600 700 800 0 100 200 300 400 500 600 Number of packets Network size Our protocol ZigBee
Figure 1: Comparison on the number of packets against ZigBee
packets than ZigBee multicast regardless of the network size. In addition, as the network size increases, the number of packets incurred by ZigBee multicast increase greatly from roughly 250 to 650 packets, while the number of packets incurred by our protocol increase slightly from 40 to 70 packets. It is not difficult to understand the results because ZigBee multi-cast exploits regional flooding to deliver the multimulti-cast packet. Each member node floods the multicast packet to the sub-network bounded by MaxNonMemberRadius hops. Moreover, without any acknowledgement mechanism, each node receiving the multicast packet blindly broadcasts the packet for 3 times. Therefore, ZigBee multicast incurs a large number of packets during the multicast packet propagation. The larger network size causes more nodes to participate in the packet propagation, each of which performs the regional flooding and the blind retransmissions and thereby largely increases the number of packets transmitted.
0 5 10 15 20 25 30 0 100 200 300 400 500 600 Latency(ms) Network size Our protocol ZigBee
Figure 2: Comparison on transmission latency against ZigBee
On the other hand, our protocol takes advantage of the coverage-over-cost ratio to reduce the number of forwarders. Besides, our protocol provides an overhear-based acknowledgement mechanism to further reduce the packets resulting from retransmissions. Thus, our proto-col incurs much fewer packets and, when the network size grows, the increased amount of packets is little.
We also evaluate the latency of the packet propagation. The transmission latency is measured as the time elapsed when the multicast packet initiated by the multicast source is received by all the group members. As shown in Fig. 2, both of the latencies for ZigBee multicast and our protocol are decreasing as the network size increases. With the growth of the network size, the number of each node’s neighbors increases, and some of them might be capable of reaching more members within MaxNonMemberRadius hops. Therefore, the
total length of the packet delivery path might be shorter, so the latency decreases. The latency of our protocol is shorter than ZigBee multicast. As we mentioned above, ZigBee multicast exploits regional flooding to deliver the multicast packets and relies on blind retransmissions as an acknowledgement mechanism. These two reasons lead to extremely heavy traffic, so the probability of packet collision increases. If a node transmits a packet, and the packet collides with others, the node has to wait until its retransmission time arrives to retransmit the packet, and the probability of packet collision is still high at that time. In contrast, there is no such problem in our protocol since the traffic produced by our protocol is much lighter. Therefore, the latency for our protocol is shorter than ZigBee multicast.
Fig. 3 and Fig. 4 show the impact of the group size on the total number of packets and transmission latency. We fix the network size to 300 nodes, and vary the group size from 10 to 50 members. It is not surprising to see that as the group size increases, both the number of packets and transmission latency increase because it needs more forwarders and takes more time to deliver the multicast packet to the group members when the network size grows. Therefore, both the number of packets and the latency are increasing. In spite of the growth of the network size, our protocol still outperforms ZigBee in the number of packets and the transmission latency.
0 100 200 300 400 500 600 0 10 20 30 40 50 60 Number of packets Group size Our protocol ZigBee
Figure 3: Impact of group size on the number of packets
0 5 10 15 20 25 30 35 40 0 10 20 30 40 50 60 Latency(ms) Group size Our protocol ZigBee
0 200 400 600 800 1000 1200 1400 ZigBee Our protocol Time elapsed(second) Our protocol ZigBee
Figure 5: Comparison on network lifetime when the first node death occurs
0 2000 4000 6000 8000 10000 12000 14000 16000 18000 ZigBee Our protocol
Number of multicast accomplished
Our protocol ZigBee
22 24 26 28 30 32 34 36 38 40 42 0 5 10 15 20 25 30 0 5 10 15 20 25 30 0 20 40 60 80 100 Residual energy(Joule)
Residual energy after 8000 multicasts
x axis
y axis Residual energy(Joule)
Figure 7: Residual energy of each node after 8000 multicasts in ZigBee
65 70 75 80 85 90 95 100 0 5 10 15 20 25 30 0 5 10 15 20 25 30 0 20 40 60 80 100 Residual energy(Joule)
Residual energy after 8000 multicasts
x axis
y axis Residual energy(Joule)
Next, we conduct several experiments to verify the load balance effect of our protocol. We deploy 100 nodes in the network with 10 members randomly chosen. First, we evaluate the time elapsed and the number of packets successfully delivered to the members when the first node having exhausted its energy appears, i.e., the first node death. In each multicast session, the multicast source is randomly chosen among the members, and the multicast sessions are initiated after the previous one has ended. As shown in Fig. 5, the network lifetime of our protocol is more than 2.78 times longer than that of ZigBee multicast, when the first node death occurs. The number of multicast sessions which successfully deliver the multicast packets to all members until the first node death occurs is shown in Fig. 6. Our protocol successfully delivers 1.79 times more packets to the members. Fig. 7 and Fig. 8 show each node’s residual energy after 8000 multicasting under ZigBee multicast and our protocol. The average residual energy of the nodes after 8000 ZigBee multicasts is 31.2 joules, while the average residual energy is 81.5 joules by using our protocol. Also, the energy consumption is more balanced using our protocol. The results shown in Fig. 5 to Fig. 8 prove the effectiveness of our idea of taking into account each node’s residual energy when choosing forwarders. As a matter of fact, because the nodes with more residual energy have higher probability to forward the packets, the packet delivery path dynamically adapts
0 20 40 60 80 100 0.5 0.6 0.7 0.8 0.9 1 Delivery ratio(%) Link Stability Our protocol ZigBee
Figure 9: Impact of link stability on the delivery ratio
to the instant network condition as the energy of each node depletes. As a result, the energy consumption is evenly distributed among the nodes in the network, and not only the network lifetime is extended but also the single-node-failure problem is avoided.
Finally, we study the reliability of our protocol. Similarly with the previous experiments for load balance, we also deploy 100 nodes in the network with 10 members randomly cho-sen. We evaluate the delivery ratio under different link stability. The delivery ratio is mea-sured as the percentage of the number of multicast packets successfully delivered to all the group members. The link stability represents the probability that a packet is successfully received by the nodes within the senders’ communication range. As shown in Fig. 9, when the link stability is greater than 90%, our protocol is able to achieve completely successful delivery, while ZigBee only reaches 90% due to the heavy traffic caused by the regional
flooding and the blind retransmissions. Clearly, in both our protocol and ZigBee multicast, as the link stability is getting more unstable, the delivery ratio is lower. The delivery ratio in ZigBee multicast is much lower because it suffers from the ineffectiveness of the blind re-transmission. We know that ZigBee multicast relies on the blind retransmissions to increase its reliability. However, when the link is unstable, the blind retransmissions might not take effect because they might not be successfully sent to the receivers. As you can see, when the link stability is worse than 70%, the delivery ratio of ZigBee multicast drops to under 75%. The delivery ratio even drops to only 30% when there is a half chance that the packet transmission fails. On the other hand, our protocol is able to achieve more than 85% delivery ratio when the link stability is greater than 70%.
5 Conclusions
We have studied the energy-efficient multicast problem in WSNs. Due to the limited power resource of sensor nodes, energy-efficient multicast is a critical issue in WSNs. ZigBee is a cost-effective wireless networking solution with the features including low data-rates, low-power consumption, security, and reliability. Although ZigBee is widely adopted in WSNs, ZigBee multicast is energy-inefficient and unreliable. Many other approaches have been pro-posed, but they fail to achieve energy efficiency and load balance at the same time. Moreover, these proposed approaches do not support dynamic member joining and leaving. In this pa-per, we present a ZigBee compatible, energy-efficient, load-balanced, and reliable multicast protocol which supports dynamic member joining and leaving. Our protocol adopts a prob-abilistic anycast mechanism to realize multicast communication. As the network topology changes or the node’s energy depletes, our protocol can adapt to the instant network condi-tion since it considers the coverage-over-cost ratio as well as the residual energy among the candidate forwarders. Therefore, our protocol is able to achieve energy efficiency and load balance at the same time. Simulation results show that our protocol provides longer network lifetime and outperforms ZigBee in energy consumption, latency, and reliability.
References
[1] Zigbee Alliance. http://www.zigbee.org/.
[2] Q. Cao, T. He, and T. Abdelzaher. ucast: Unified connectionless multicast for energy efficient content distribution in sensor networks. IEEE Transactions on Parallel and
Distributed Systems, 18:240–250, 2007.
[3] C.-K. Chiang and C.-T. King. Source routing for overlay multicast in wireless ad hoc and sensor networks. In Proc. of IEEE Int’l Conference on Parallel Processing
Work-shops (ICPPW), 2007.
[4] C. Gui and P. Mohapatra. Overlay multicast for manets using dynamic virtual mesh.
Wireless Networks, 13:77–91, 2007.
[5] T. He, C. Huang, B. M. Blum, J. A. Stankovic, and T. Abdelzaher. Range-free local-ization schemes for large scale sensor networks. In Proc. of ACM Int’l Conference on
Mobile Computing and Networking (MobiCom), pages 81–95, 2003.
[6] W. R. Heinzelman, A. Chandrakasan, and H. Balakrishnan. Energy-efficient communi-cation protocols for wireless microsensor networks. In Proc. of Hawaii Int’l Conference
on Systems Science (HICSS), 2000.
[7] C.-F. Huang, Y.-C. Tseng, and L.-C. Lo. The coverage problem in three-dimensional wireless sensor networks. Journal of Interconnection Networks, 8(3):209–227, 2007. [8] X.-M. Huang and J. Ma. Optimal distance geographic routing for energy efficient
wireless sensor networks. International Journal of Ad Hoc and Ubiquitous Computing, 1(4):203–209, 2006.
[9] J. hwan Chang, L. Tassiulas, and R. Tassiulas. Energy conserving routing in wireless ad-hoc networks. In Proc. of IEEE INFOCOM, 2000.
[10] IEEE standard for information technology - telecommunications and information ex-change between systems - local and metropolitan area networks specific requirements part 15.4: wireless medium access control (MAC) and physical layer (PHY) specifica-tions for low-rate wireless personal area networks (LR-WPANs), 2003.
[11] M. Kochhal, L. Schwiebert, and S. Gupta. Role-based hierarchical self organization for wireless ad hoc sensor networks. In Proc. of ACM Int’l Workshop on Wireless Sensor
Networks and Applications (WSNA), 2003.
[12] D. Koutsonikolas, S. M. Das, Y. C. Hu, and I. Stojmenovic. Hierarchical geographic multicast routing for wireless sensor networks. In Proc. of IEEE Int’l Conference on
[13] D. Li, Q. Liu, X. Hu, and X. Jia. Energy efficient multicast routing in ad hoc wireless networks. Computer Communications, 30:3746–3756, 2007.
[14] Q. Li, M. DeRosa, and D. Rus. Distributed algorithm for guiding navigation across a sensor network. In Proc. of ACM Int’l Symposium on Mobile Ad Hoc Networking and
Computing (MobiHoc), Maryland, USA, 2003.
[15] S. Meguerdichian, F. Koushanfar, M. Potkonjak, and M. B. Srivastava. Coverage prob-lems in wireless ad-hoc sensor networks. In Proc. of IEEE INFOCOM, 2001.
[16] S.-Y. Ni, Y.-C. Tseng, Y.-S. Chen, and J.-P. Sheu. The broadcast storm problem in a mobile ad hoc network. In Proc. of ACM Int’l Conference on Mobile Computing and
Networking (MobiCom), 1999.
[17] M.-S. Pan and Y.-C. Tseng. The orphan problem in zigbee-based wireless sensor net-works. In Proc. of ACM/IEEE Int’l Symposium on Modeling, Analysis and Simulation
of Wireless and Mobile Systems (MSWiM), 2007.
[18] M.-S. Pan, L.-W. Yeh, Y.-A. Chen, Y.-H. Lin, and Y.-C. Tseng. A wsn-based intelligent light control system considering user activities and profiles. IEEE Sensors Journal, 8(10):1710–1721, 2008.
[19] H. Park, M. B. Srivastava, and J. Burke. Design and implementation of a wireless sensor network for intelligent light control. In Proc. of ACM/IEEE Int’l Conference on
Information Processing in Sensor Networks (IPSN), 2007.
[20] J. Sanchez, P. Ruiz, and I. Stojmnenovic. Geographic multicast routing for wireless sensor networks. In Proc. of IEEE Sensor and Ad Hoc Communications and Networks
Conference (SECON), 2006.
[21] J. Sanchez, P. Ruiz, and I. Stojmnenovic. Energy-efficient geographic multicast routing for sensor and actuator networks. Computer Communications, 30:2519–2531, 2007. [22] A. Savvides, C.-C. Han, and M. B. Strivastava. Dynamic fine-grained localization in
ad-hoc networks of sensors. In Proc. of ACM Int’l Conference on Mobile Computing
and Networking (MobiCom), pages 166–179, 2001.
[23] K. Sohrabi, J. Gao, V. Ailawadhi, and G. J. Pottie. Protocols for self-organization of a wireless sensor network. IEEE Personal Communications, 7(5):16–27, October 2000. [24] R. Szewczyk, A. Mainwaring, J. Polastre, J. Anderson, and D. Culler. An analysis
of a large scale habitat monitoring application. In Proc. of ACM Int’l Conference on
Embedded Networked Sensor Systems (SenSys), 2004.
[26] Y.-C. Tseng, M.-S. Pan, and M.-S. Pan. A distributed emergency navigation algorithm for wireless sensor networks. IEEE Computer, 39(7):55–62, 2006.
[27] J. E. Wieselthier, G. D. Nguyen, and A. Ephremides. Energy-efficient broadcast and multicast trees in wireless networks. Mobile Networks and Applications, 7:481–492, 2002.
[28] T.-T. Wu and K.-F. Ssu. Determining active sensor nodes for complete coverage without location information. International Journal of Ad Hoc and Ubiquitous Computing, 1(1/2):38–46, 2005.
[29] J. Zhu, C. Qiao, and X. Wang. A comprehensive minimum energy routing. In Proc. of
IEEE INFOCOM, 2004.
[30] J. Zhu and X. Wang. Peer: A progressive energy efficient routing protocol for wireless ad hoc networks. 2005.
