This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the ICC 2008 proceedings.
A Scalable Low-Power WSAN Solution for Large-scale Building Automation Pieter De Mil∗ , Tim Allemeersch∗ , Ingrid Moerman∗ , Piet Demeester∗ and Wim De Kimpe† ∗ Department
of Information Technology (INTEC), Ghent University - IBBT G. Crommenlaan 8 bus 201, B-9050 Ghent, Belgium E-mail: {pieter.demil, tim.allemeersch, ingrid.moerman, piet.demeester}@intec.ugent.be † GreenPeak Technologies Lindestraat 19, B-9240 Zele, Belgium E-mail:
[email protected] Abstract—Nowadays, wireless sensor and actuator networks are a hot issue because they can enable the Internet of Things at little expense. Research activities mainly focus on one aspect of these networks (e.g. energy consumption) neglecting others (e.g. latency, scalability). Aspects like energy reduction, scalability, Quality-of-Service, and reliability are key requirements in our envisaged heterogeneous applications for sensor and actuator networks in commercial/residential buildings consisting of 1000+ nodes. In this paper, a stack which meets these requirements is proposed. We found that simulations only are not sufficient when developing WSAN solutions. We showed that it is possible to combine low-power with low-latency on large-scale QoS-aware networks.
I. I NTRODUCTION Deploying a Wireless Sensor and Actuator Network (WSAN) in a commercial or residential building brings many benefits. Heating, ventilation, locks and lighting are all interconnected and can be controlled centrally. If an IP gateway is present, the sensor nodes can even be controlled from a remote location. In-home security can easily be upgraded by deploying smoke and motion detectors without the extra work and cost of cabling. In order to be usable in a large-scale deployment (1000+ nodes), the sensor network should apply to the following requirements: •
•
•
The sensor nodes must be as energy efficient as possible since most nodes are battery powered. We envisage a lifetime of +5 years on 2 AA batteries. Most sensor networks deployed outdoor monitor the same phenomena. In wireless building automation each sensor node has a unique role. This lack of redundancy requires a highly reliable WSAN. Data sent over a sensor network in a building can be time critical. Therefore the network must be low-latency.
Standards like ZigBee [1] can provide a solution for sensor network deployment in commercial and residential buildings but currently have significant shortcomings (absence of lowpower routers, absence of some sort of Quality-of-Service, etc. ). In this paper we will describe a proprietary solution based on ZigBee/IEEE802.15.4, but with additional elements matching the requirements stated above.
The remainder of this paper is organized as follows. In the next section we will discuss our ultra-low-power solution while section III discusses scalability issues. Our QoS solution is described in section IV. Section V presents the state-of-theart in sensor networks. In the last section, we describe our conclusion. II. A N ULTRA - LOW- POWER WIRELESS SENSOR NETWORK The absence of low-power routers in current standards like ZigBee/IEEE802.15.4 is an insuperable issue, especially when considering true low-power sensor networks, where all nodes are battery-powered. In networks of 1000+ nodes that do not use some sort of energy-saving (through a novel MAC protocol) or energy-harvesting, the monitoring and replacing of the batteries would be a full-time job which is contradictory if ease of use and easy deployment are required. In this section we will discuss PeakNet LPR, a MAC protocol that supports low-power routing, without introducing intolerable latencies. Techniques to reduce energy use already exist. In asynchronous networks, data packets are preceded with a burst of wake-up tokens (the preamble) to alert the destination that it must stay awake to receive the data. This approach is shown in Fig. 1. A major drawback is the energy wasted when sending tokens. A different approach (Fig. 2) is possible (but not defined for mesh PANs) within the IEEE 802.15.4 standard [2]. Here, all nodes are synchronized by tracking beacons of their parent. The parent-child communication takes place in the superframe of the parent. However, this leads to long latencies, especially
Fig. 1. Asynchronous MAC protocol to reduce energy. Node A wants to send data to node B. It sends a burst of tokens to make sure node B will stay awake. After the preamble, node A sends the data packet.
978-1-4244-2075-9/08/$25.00 ©2008 IEEE
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the ICC 2008 proceedings.
Beacon Interval A B C
Send Beacon
Communication With Childs
Track Parents Beacon
Communication With Parent
Fig. 2. In the IEEE802.15.4 standard, energy is saved by dividing time in superframes. Parent and child can communicate in the superframe of the parent, leading to high latencies (in combination with long beacon periods).
with long duty cycles (i.e. long beacon periods in the order of 10-100s) in combination with many hops. PeakNet LPR, the MAC protocol discussed in this paper, is a combination of these techniques, maximizing the strengths and minimalising the weaknesses of both. PeakNet LPR introduces a network-wide synchronization - all nodes switch their microcontroller and radio on at the same moment. One node (the PAN Coordinator) starts sending beacons and is the clock source of the network. Note that the beacons contain useful information for the nodes. We do not just send beacons to provide synchronization. Each node in the network synchronizes by tracking his parents beacon and provides synchronization to other nodes by sending beacons itself. After receiving the beacon from his parent, the clock will be adjusted in order to limit the clock drift. However, making the system low power does not mean that we can compromise robustness. If the parent node would fail, its children would loose synchronization and would have to start associating again. This is unacceptable. Therefore, in addition to the parent beacon, the nodes will track some alternative parents. If a parent fails, a node will immediately swap to the best alternative parent. This way, the nodes stay synchronized with the network and they have all the same notion of time, without resulting in synchronized clusters. Swapping to an alternative parent is not possible for all(!) the one-hop neighbours of the PAN Coordinator. If the PAN Coordinator fails, the network needs a new, single clock source. We suggest two solutions. One possbile solution for this single point of failure is a mechanism so that one of the one-hop neighbours becomes temporarily the new clock source. Another solution could make it possible that one of the other sinks becomes responsible for the clock source. Here we assume that the sinks and the PAN Coordinator can communicate with each other via a backbone network. We have not encountered a failing PAN Coordinator in our real-life tests, but we are aware that this can happen. The suggested solutions are left for future work. In a real-life environment, the PAN Coordinator starts sending beacons when it is installed. All the other nodes will scan and search for beacons on a preconfigured channel. This process takes two times the beacon interval. A node at hop distance two can only find beacons if a node closer to the
PAN Coordinator is already synchronized. It is true that, the first time, it will take max hops*2*BI before every node in the network is synchronized. For example: a 1000 hop network with a beacon interval of 10 seconds results in a worst-case one-time delay of 5,55 hour. This one-time delay is no problem because an installer can probably not install 1000 nodes that quickly. Our network-wide synchronization enables all nodes to wake up at the same moment. This implies only one token needs to be sent in contrast to the burst of tokens needed in the asynchronous approach. Our approach reduces the energy used. PeakNet LPR also introduces a new frame structure; instead of the IEEE802.15.4 superframe structure, a sync slot structure is used. Each beacon interval is divided into a number (max. 64) sync slots with a duration of 250-500 ms. Fig. 3 displays PeakNet LPR. The shorter the sync slot, the lower the latencies will be. At the start of a sync slot, nodes send/track beacons (this is called the beacon slot). The second half is reserved for data packets (data slot or IWU moment). In this way, we also prevent collisions between beacons and data messages. This is important because our synchronization is based on the reception of beacons. When a node has data to send, it will wait until an IWU moment, when all nodes are awake to send a token to the destination. Remember that we do not allocate an IWU moment between a pair of nodes. After this short (3 ms) token sniffing period, all nodes that have not received a token will go to sleep again. The nodes that received a token will stay awake for the data and go to sleep after reception of that data packet. Combining a beacon enabled network to establish synchronization, with a superframe split in different communication slots and with an on-demand wake-up scheme, enabled us to minimize power consumption and to establish low-latency mesh communication. Fig. 4 shows that our solution is true low-power. Even with a simple coin cell, the network is able to live multiple years. With 2 AA batteries the lifetime is even higher. PeakNet LPR has been ported to simulator (NS2 [3]) and hardware (CM-08 module [4]) for a proof of concept demonstrator. We can conclude that PeakNet LPR
Beacon Interval Sync Slot (250-500ms) A B C D A B
Send Beacon D
Track parents beacon
Track alternative parents beacon Communication slot (data/control packets)
C
Fig. 3. PeakNet LPR. All nodes wake up (RX on) synchronized. When all nodes are awake (=Induced Wake-Up (IWU) moment) data packets can be sent using CSMA/CA. Each beacon interval the nodes will wake up when a beacon from their parent or alternative parent is expected.
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the ICC 2008 proceedings.
enables topologies with low-power routers which enables new applications. All nodes in the network can be powered by batteries or by energy harvesters, not only getting rid of the communication cable, but also the power cable. III. S CALABILITY IN W IRELESS S ENSOR N ETWORKS In this section we present two techniques that make the WSAN scalable. First we will describe the Distributed Assignment of Beacon Slots (DABS). The importance of DABS is preventing collisions between beacons of neighbouring nodes. To our knowledge, this is the first distributed solution for the scheduling of beacon frames. Next, we describe the detection of multiple sinks and the reaction if a sink fails. A. Distributed Assignment of Beacon Slots The number of beacon slots (#BS) in a beacon interval is limited and determined by the Sync Slot Order (SSO): #BS = 2SSO
(1)
An SSO of 6 means we have 64 available sync slots, and consequently 64 beacon slots. If the central PAN Coordinator assigns the sync slot id to associating nodes we can allow maximum #BS-1 extra nodes in the network. Indeed if all the beacon slot ids are already used, the PAN Coordinator can not deal out a guaranteed collision free beacon slot to a new node. Clearly this central approach without extra information is not scalable and generates a lot of message overhead. With a distributed assignment of beacon slots, each node has to choose a beacon slot that is unique in the 2-hop neighbourhood. Therefore, a new node needs some information about the used beacon slots in the neighbourhood. Each associated node knows which slots are occupied in the 1-hop neighbourhood. The nodes stores this 1-hop information in
the beacon payload which is published every beacon interval. When a new node scans the medium, it will receive the beacons of all the neighbours within the POS. At this moment the node has an overview of all the used beacon slots in his 2-hop neighbourhood. The algorithm will choose randomly a free beacon slot id and send an 1-hop broadcast to inform the direct neighbours about the chosen beacon slot. Every direct neighbour checks if there is a conflict. In case the chosen beacon slot was not free anymore, the node has to choose a new beacon slot id. This situation can happen if two or more nodes start up at the same moment within the same POS or within the 2-hop neighbourhood of a common neighbour. If both nodes chose the same sync slot id, the last node announcing this id will have to choose a new id. If a neighbour detects that two (or more) nodes use the same sync slot id, it will send a response to the latest informer(s) of the chosen sync slot id. In Fig. 5, we see five nodes, labeled from A to E. A is the PAN Coordinator and starts sending beacons periodically in sync slot 0. Since node A does not hear another node, it just stores its own sync slot id in the beacon payload. Next, node B is turned on and receives only one beacon indicating there are four sync slots and slot 0 is already occupied. B chooses randomly id 1 and lets this know to the direct neighbours. Thus A updates the beacon payload from (0) to (0,1). B also stores (0, 1) in its own beacon. After the succesfull join of node C, node A is advertising (0, 1), node B (0, 1, 2) and node C (1, 2). Node D receives the beacons from B and C, and has to pick sync slot 3. After the succesfull join of node C, node A is still advertising (0, 1), node B updates to (0, 1, 2, 3) and node C updates to (1, 2, 3). The fifth joining node, E, only hears the beacon of node D and can send his beacon on sync slot 0. This same slot is unique in the 2-hop neighbourhood and both node A and E are sending their beacons collision-free at the same time. Note that PeakNet LPR is not affected by hierarchical synchronization [5] constraints: nodes at different depths can share the same sync slot id, as long as they are not in the 2-hop neighbourhood. If a node can not track the
Beacon Interval Sync Slot
A
A C
B
B D
Fig. 4. In every communication interval a 1 byte sensor reading is sent upstream in the network from the leaf node towards the coordinator. The battery is a 220 mAh CR2032 3V coin cell. This graph shows the battery life in years for the leaf node in function of the communication interval.
E
C
Beacon
D
Beacon Slot Data Slot
E
Sync Slot ID:
Fig. 5.
0
1
2
3
DABS with 5 nodes and only 4 beacon slots.
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the ICC 2008 proceedings.
TABLE I
40
NS -2 SIMULATION SETTINGS
With RTS/CTS 35
Without RTS/CTS
Channel/WirelessChannel Propagation/TwoRayGround Phy/WirelessPhy802 15 4 Peak Net S Mac/802 15 4 Peak Net S Antenna/OmniAntenna
# packets received correctly
val(chan) val(prop) val(netif) val(mac) val(ant)
30
25
20
15
beacon of the first parent, it will switch to an alternative parent and stay synchronized. We have implemented this both in the network simulator ns-2 and on real hardware from GreenPeak Technologies. For the simulations, we started from the IEEE 802.15.4 implementation of Zheng [6] and extended it to support beaconed mesh topologies. Next we have built a network layer on top of the SSCS sub-layer. In Table I, the simulation settings are shown. Both the simulations and real experiments worked as expected. Remember that this mechanism is only for beacon messages, not for data messages. B. Multiple Sinks In our WSAN, sensors send their measurements to the Building Management System and commands are send to the actuators. Allowing thousands of nodes makes it necessary to introduce multiple sinks. A new sink has to join the network before it advertises itself as a sink. We added two extra fields in the beacon payload: one for the sink network address and another for the cost to that extra sink. In order to be as energyefficient as possible, a node only tracks two beacons (one of a parent and another of an alternative parent) and does not listen during the other sync slots. To detect the new sink it has to listen periodically on all the sync slots. We can schedule this with a parameter named FullNeighbourScan (FNS). This parameter determines after how many beacon intervals (#BI) a full neighbour scan is performed: #BI = 2F N S
(2)
During a full neighbour scan, the node will listen on all the sync slots. First, the 1-hop neighbours of the new sink will detect this sink and update the beacon payload. In this way, the existence of a new sink is propagated through the network and all the nodes can store a path to that sink if the cost is lower. There is a tradeoff between the detection of sinks and the energy-efficiency of the network. An FNS of 8 means we have to wait maximum 256 beacon intervals. Of course, detection of a new sink is not time-critical, since we are not going to install a new sink every week or month. However when a sink fails, the nodes have to send their data to another sink. It is important that nodes detect this situation quickly. The absence of beacons is noticed by the direct neighbours of a failing sink. Immediately the cost to reach that sink is increased and propagated through the network via the beacons. IV. Q O S IN W IRELESS S ENSOR N ETWORKS A. A Simplified RTS/CTS for Wireless Sensor Networks In standard always-on sensor networks, nodes can send data at any time. In the above presented low-power implementation,
10
5
0 0
5
10
15
20
25
30
35
40
45
# data packets/IWU moment
Fig. 6. A simulated scenario with multiple nodes associating at the same moment. With RTS/CTS all association packets get through, without RTS/CTS packets get lost due to collisions.
nodes will only try to send their data when all nodes in the network are awake. In times of network congestion this approach may lead to collisions since many nodes will send tokens at the same time. A hidden node may also lead to collisions. To address these problems we introduced a simplified RTS/CTS scheme. The token acts as an RTS (Request-toSend). After a node has sent a token, it will stay awake for the CTS (Clear-to-Send). If no CTS was received, the node will go asleep and will try again the next IWU moment. Simulations have shown great improvements when using RTS/CTS in dense networks, specifically during the association process. When multiple nodes are starting up at the same time (e.g. after a power failure), they will send their association request at the exact same IWU moment (namely the first IWU moment after they have synchronized), leading to massive collisions. Using the proposed RTS/CTS scheme, all nodes wait their turn, and associate in an orderly fashion. The node receiving the association requests (parent node) acts as a traffic agent controlling data flow by sending 1 CTS per IWU moment. A scenario with 40 nodes sending data packets to the same parent, at the same IWU moment was simulated using NS2-29. The results of this simulation are reflected in Fig. 6. In Fig. 7, we have defined a small testbed scenario in which a number of nodes (maximum six) simultaneously want to send one data packet to a sink (that is one hop away). All the nodes can hear each other. We were interested in the effect on the maximum delay. The results represent the average of 10 runs on TmoteSky [7] modules. With RTS/CTS, we see that all nodes wait their turn as expected and for six nodes we need of course six IWU slots. Remember that with RTS/CTS, a node can send only one data packet in an IWU slot. Another node has to wait until the next IWU slot and has to try again to win the CTS. Without RTS/CTS, we noticed that the average maximum delay is lower for up to four nodes. Because other nodes do not have to wait until the next IWU slot, the delay is lower (here CSMA/CA will try to avoid collisions). If four
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the ICC 2008 proceedings.
Fig. 7. A testbed scenario with multiple nodes simultaneously sending data. We can see the effect of RTS/CTS on the average maximum delay (in number of IWU slots)
or more nodes want to send simultaneously data, the average maximum delay is higher because more collisions happen. We conclude that without RTS/CTS, many collisions occur due to the hidden node problem and CSMA/CA failing. RTS/CTS avoids these collisions by acting as a traffic agent. On real hardware, the nodes will not wake up at the exact same moment due to a certain clock drift (drift of up to 1.5 ms is tolerated). This drift was absent in the simulation. The same test on hardware will have better results without RTS/CTS than the simulator results. Therefore, we are convinced that a drift model should be added to the simulator environment. B. Quality-of-Service in Wireless Sensor Networks Sensor and actuator networks will consist of hetergeneous nodes (light switches, smoke and motion detectors, temperature sensors for HVAC, etc. ). Each of these hetergeneous nodes (or applications) will have different requirements regarding latency, reliability, lifetime of messages, etc. . Data originating from a light switch will have limited reliability requirements. In contrast, the latency is very critical. For security related nodes like smoke detectors, a strict reliability is required. Because of this heterogeneity, it is unlikely that there will be one QoS solution that fits all applications. In this section, we propose a QoS solution that divides the packets in different QoSClasses depending on their requirements. Applications can choose from eight classes where the lower classes have priority over the higher ones. We add the QoS class of a data message in the RTS token. Class 0-2 have a special purpose, targeted at wireless building automation applications. Class 2 introduces an end-to-end acknowledgement. It is used by applications that require a strict reliability (e.g. smoke detector). Class 1 is reserved for packets that must have priority over the packets of class 2. This class is rarely used. Class 0 includes a time-to-live field. This parameter specifies the maximum number of IWU moments the packet has to reach its destination. It is decremented every IWU moment, and the packet is discarded when it reaches 0. QoSClass 0 is useful considering following scenario: a person presses a light switch (source), and he/she wants
Fig. 8. Node A and B simultaneously try to get access to the medium. Node A has a high priority packet and chooses a low QoSClass. Therefore, it will get access to the medium while node B will wait. The high priority packet will reach the sink first.
to see the light (destination) switch on within 0.5s. Light switch data will therefore have QoSClass 0 and a time-tolive corresponding to 0.5s. When the packet is delayed due to network congestion and it can not reach its destination within the postulated time-to-live, it will be dropped. Therefore, when a user presses the switch a second time (he/she thinks his first action was not sent because the light is not responding) there won’t be duplicate packets in the network that would have the light going on for a short time and then switch off again. To test our QoS solution, we simulated the scenario presented in Fig. 8. Node A and B both send a data packet at the same IWU moment to the sink through a router R. If QoS is used, the high priority packet of node A (QoSClass 3) reaches the sink first. If no QoS is implemented it is completely random which packet will reach the sink first. This scenario has also been tested on hardware in a real-life setting. The average delay of 50 measurements is displayed in Fig. 8. With QoS, the packet of node A reaches the destination within 2 IWU moments. Node B’s packet reaches the destination in 4 IWU moments. Without QoS sometimes node A will get priority, other times, node B will be first. This leads to an average delay of 3 IWU moments. The simulation results correspond very well with the hardware results. To support our QoS solution, we implemented a MAC-level priority queue. In this queue, the high priority packets are at the front. To lower the risk that low priority packets are continuously passed, older packets in the queue can get the chance to climb up in the queue. Packets of class 0 are never passed due to their strict timing requirements. Both hardware and simulator tests have shown the benefits of our QoS solution. A smoke detector in a building can now choose the best QoSClass for its needs; if it wants to send a status update, it will choose a high QoSClass. If there is an alarm, it will choose class 2 to make sure the packet will arrive.
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the ICC 2008 proceedings.
V. S TATE - OF - THE - ART Researchers have proposed various MAC protocols to reduce energy consumption in sensor networks. Since idlelistening, overhearing and collisions are the main sources of energy-wastage, an energy-efficient MAC will save energy by maximizing sleep time [8]. To summarize, two approaches can be followed: the synchronous and the asynchronous approach. S-MAC [8], [9] and T-MAC [10] are examples of synchronous MAC protocols where periodically, all nodes wake up to send and receive data. Nodes know when their neighbor will wake up and buffer data for those neighboring nodes until they are awake. Even though these protocols reduce the energy consumed, they also introduce an extra latency which can be significant for low-duty cycling networks where nodes sleep most of the time. In S-MAC, not all neighbouring nodes can synchronize together in a multi-hop network. Two neighbouring nodes A and B may have different schedules if they each in turn must synchronize with different nodes, C and D, respectively. The downside of the scheme used in S-MAC is that the latency is increased due to the periodic sleep of each node. Moreover, the delay can accumulate on each hop. In our protocol, each node can send to each neighbour and the delay can not accumulate on each hop. B-MAC [11] is an example of an asynchronous MAC protocol. When a node has to send data, it sends a preamble that is at least as long as the sleeping period of the destination. This approach is also called low-power listening (LPL). XMAC [12] improves B-MAC by including the source address in the preamble to reduce idle listening and by giving the destination node the chance to stop the preamble if it is awake before the end of the preamble period. Wisemac [13] reduces the preamble length by enabling the nodes to learn the sleep/wake-up scheme of its neighbours. Nowadays environment monitoring [14] is a popular application for sensor networks. The energy-efficient approaches discussed above may work perfectly in the monitoring application, but theymight struggle in a wireless building application where reliability, latency, scalability, ease of use and deployment and Quality-of-Service are increasingly more important. In [5] the authors state correctly that we can reuse the same beacon slot, if the coordinators are location-aware. A scalable network with a central assignment of beacon slots is possible if every associationg node sends his location information. The authors have proposed two beacon frame scheduling mechanisms: one for the time division approach and another one for the beacon-only period approach. In [15] the performance of multi-sink scenarios is determined, but each sink is the root of an own tree. In our implementation a node can be part of multiple trees, which is more robust. VI. C ONCLUSION We have proposed a network solution for wireless sensor networks in a wireless building automation scenario. Our solution takes into account the various limitations and challenges when deploying a large-scale sensor network in residen-
tial/commercial buildings like energy-efficiency, Quality-ofService, scalability, and reliability. We found that simulations only are not sufficient when developing WSAN solutions (e.g. the natural clock drift of nodes is absent). Our solution has been simulated as well as evaluated and demonstrated on hardware in a realistic environment. To further evaluate our algorithms, we envisage an extensive test on a testbed of 180+ nodes. ACKNOWLEDGMENT For their contribution to the WBA [16] project, the authors further acknowledge all partners of the IBBT WBA consortium (Arts Centre Vooruit, GreenPeak Technologies, Niko, Siemens-Nokia networks, Televic, Telindus, One-Access, IMEC-DESICS, KULeuven-COSIC, KULeuven-ICRI, UAPATS, UGent-IBCN, UGent-MMLab, VUB-ETRO). R EFERENCES [1] ZigBee Alliance, http://www.ZigBee.org, September 2007. [2] IEEE-TG15.4, Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (LR-WPANs), IEEE standard for Information Technology, 2003. [3] UCB/LBNL/VINT, Network Simulator-ns, http://nsnam.isi.edu/nsnam/, February 2008. [4] GreenPeak Technologies, Lime CM-08 Datasheet, http://www.greenpeak.com/Press/PressKit/CM-08 Datasheet rev1.7.pdf, February 2008 [5] A. Koubaa, M. Alves, M. Attia, A. Van Nieuwenhuyse, Collision-Free beacon scheduling mechanism for IEEE 802.15.4/Zigbee cluster-tree wireless sensor networks, in Proc. of the 7th International Workshop on Applications and Services in Wireless Networks (ASWN2007), Santander, Spain, May 2007. [6] J. Zheng and Myung J. Lee, IEEE 802.15.4 implementation for ns-2, http://ees2cy.engr.ccny.cuny.edu/zheng/pub/, February 2008. [7] MoteIV, TmoteSky, http://www.moteiv.com/community/Tmote Sky Downloads, February 2008. [8] Wei Ye, John Heidemann, and Deborah Estrin, Medium Access Control with Coordinated, Adaptive Sleeping for Wireless Sensor Networks, IEEE Transaction on Networking, 12(3):493-506, June 2004. [9] Wei Ye, John Heidemann, and Deborah Estrin, An Energy-Efficient MAC Protocol for Wireless Sensor Networks, in Proc. IEEE Infocom, pages 1567-1576, New York, NY, June 2002. [10] Tijs Van Dam and Koen Langendoen, An Adaptive Energy-Efficient MAC Protocol for Wireless Sensor Networks, in Proc. of the first ACM SenSys Conference, pages 171-180, California, USA, November 2003. [11] Joseph Polastre, Jason Hill, and David Culler, Versatile Low Power Media Access for Wireless Sensor Networks, in Proc. of the 2nd ACM SenSys Conference, pages 95-107, Baltimore, MD, USA, November 2004. [12] Michael Buettner, Gary Yee, Eric Anderson, and Richard Han, XMAC: A Short Preamble MAC Protocol for Duty-Cycled Wireless Sensor Networks, in Proc. of the 4th international conference on Embedded networked sensor systems, pages 307-320, Boulder, Colorado, USA, 2006. [13] Amre El-Hoiydi, and Jean-Dominique Decotignie, WiseMAC: An Ultra Low Power MAC Protocol for Multi-Hop Wireless Sensor Networks, Lecture Notes in Computer Science, volume 3121/2004, pages 18-31, Springer-Verlag, July 2004. [14] A. Mainwaring, J. Polastre, R. Szewczyk, D. Culler, J. Anderson, Wireless Sensor Networks for Habitat Monitoring, in Proc. of the 1st ACM International Workshop on Wireless Sensor Networks and Applications, pages 88-97, Atlanta, Georgia, USA, 2002. [15] E. Cipollone, F. Cuomo, S. Della Luna, U. Monaco and F. Vacirca, Topology Characterization and Performance Analysis of IEEE 802.15.4 Multi-Sink Wireless Sensor Networks, in Proc. of the 6th Annual Mediterranean Ad Hoc Networking WorkShop, Corfu, Greece, June 2007. [16] Wireless Building Automation, https://wba.ibbt.be/, February 2008.