Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Increasing ZigBee Network Lifetime With X-MAC

Increasing ZigBee Network Lifetime With X-MAC

Ratings: (0)|Views: 7 |Likes:
Published by Usman M. Nooruddin

More info:

Published by: Usman M. Nooruddin on Dec 28, 2011
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





Increasing ZigBee Network Lifetime with X-MAC
Pablo Suarez and Carl-Gustav Renmarker
Saab Communication
suarez, renmarker
@saabgroup.comAdam Dunkels and Thiemo Voigt
Swedish Institute of Computer Science
The ZigBee standard builds on the assumption that in-frastructure nodes have a constant power supply. ZigBeetherefore does not provide any power-saving mechanisms forrouting nodes, which limits the lifetime of battery-poweredZigBee networks to a few days. This short lifetime drasti-cally restricts the possible application scenarios for ZigBee.To expand the usefulness of ZigBee, we present a ZigBeeimplementation where we replace the default ZigBee MACprotocol with the power-saving MAC protocol X-MAC. OurresultsshowthatX-MACreducesthepowerconsumptionforZigBee routing nodes with up to 90%, leading to a ten-foldincreaseinnetworklifetimeatthepriceofaslightincreaseinnetwork latency. Furthermore, we are the first to experimen-tally quantify the energy-efficiency of X-MAC in a multi-hop scenario. Our results indicate that X-MAC reduces thepower consumption of idle nodes that are within commu-nication range of two communicating nodes, suggesting thatX-MAC may be able to mitigate the hot-spot problem in sen-sor networks.
Categories and Subject Descriptors
C.2.4 [
Computer Communication Networks
]: Dis-tributed Systems—
 Network Operating Systems
General Terms
Design, Experimentation, Measurement, Performance
Wireless sensor networks, MAC protocols, ZigBee
1 Introduction
Communication is the largest power consumer in state-of-the-art sensor network hardware [9]. To achieve a longnetwork lifetime, the sensor nodes must turn their com-munication device off as much as possible. To supportmulti-hop communication, receiving nodes must be awake
Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full citationon the first page. To copy otherwise, to republish, to post on servers or to redistributeto lists, requires prior specific permission and/or a fee.
April 1, 2008, Glasgow, United Kingdom.Copyright 2008 ACM 978-1-60558-123-1/08/0004 ...$5.00
when a sending node transmits packets. Several mechanismsfor synchronizing senders and receivers have been devel-oped [2, 8].The ZigBee standard [15] is designed around the assump-tion that routing nodes have a constant power supply. Suchnodes therefore never need to save energy by switching off their radio. This makes ZigBee unsuitable for applicationswhere it is impossible to draw power cables to routing nodes.To make ZigBee useful for a class of new application sce-narios, we investigate the use of the X-MAC power-savingMAC protocol [2] in the ZigBee stack. We have imple-mented a ZigBee stack for the Contiki operating system [4],based on the Open-ZB stack [3], on top of the Contiki imple-mentation of X-MAC. We quantify the power consumptionwith Contiki’s built-in energy estimation feature [5] runningon a set of Tmote Sky boards [9].The contributions of this paper are threefold. First, weexperimentally demonstrate that X-MAC reduces the powerconsumption of ZigBee routing nodes up to 90%, leading toa ten-fold increase in network lifetime. Second, we are thefirst to experimentally quantify the energy-efficiency of X-MAC in a multi-hop scenario and to experimentally confirmthat the optimal listen-and-sleep cycle model by Buettner etal. [2] indeed provides power-efficient duty cycling config-urations. Third, we experimentally quantify the trade-offsbetween energy consumption, X-MAC duty cycle, and net-work latency. Our results indicate that X-MAC reduces thepower consumption of idle nodes that are within communi-cation range of two communicating nodes. This suggeststhat X-MAC may be able to mitigate the hot-spot problem insensor networks.The rest of this paper is structured as follows. In Sec-tion 2 we present an overview of the ZigBee stack and theX-MAC protocol. After describing our implementation inSection 3, we present our experimental results in Section 4.Before concluding the paper in Section 6 we discuss relatedwork in Section 5.
2 Background
ZigBee is an open standard for low-power, wireless net-worked monitoring and control [15]. The ZigBee stack consists of four layers, as shown in Figure 1: Application(APL), Network (NWK), Medium Access Control (MAC),and Physical (PHY).Strictly speaking, only the NWK and APL layers belong
Application (APL)Medium Access Control (MAC)Physical (PHY)Network (NWK)
Figure 1. ZigBee protocol stack.
to the ZigBee stack. The PHY and MAC layers are speci-fied by the IEEE 802.15.4 standard, but the ZigBee specifica-tion requires the NWK and APL layers to run over 802.15.4.ZigBee supports several network topologies and two typesof devices: Full Function Devices (FFD), that can performall available operations within the standard, including rout-ing mechanism or coordination tasks; and Reduced FunctionDevices (RFD), that implement a limited version of the IEEE802.15.4 protocol. The RFDs do not route packets and mustbe associated with an FFD. The current ZigBee standard re-quires FFDs to be always on, which in practice means thatFFDs must be constantly powered. Battery-powered FFDshave a lifetime on the order of a few days.X-MAC [2] is a power-saving MAC protocol that is de-signed to run on top of the 802.15.4 PHY. X-MAC reducesthe power consumption by switching the radio on and off at regular intervals. To send a packet, a node broadcasts atrain of short strobe packets. The strobe packet train is longenough to allow all nearby devices to be switched on at leastonce. After receiving a strobe packet, a node turns on itsradio in preparation of receiving a full packet. As an opti-mization for unicast packets, the strobe packets include theaddress of the receiver of the full packet. When receiving aunicaststrobe, areceiverimmediatelysendsashortacknowl-edgment packet. The sender can then immediately send itsfull packet. Other nodes that happen to overhear the strobepackets can turn off their radios until the full packet has beentransmitted.
3 Design and Implementation
We have implemented a ZigBee stack Contiki, based onthe Open-ZB stack [3], but underlay the 802.15.4 MAC pro-tocol with the power-saving X-MAC protocol. While ourimplementation is designed to run over any radio hardware,our target hardware is the Tmote Sky [9].
3.1 Upper Layers
The ZigBee specification separates the APL layer intothree different sub-layers: the Application Support Sublayer,the ZigBee Device Objects, and Manufacturer Defined Ap-plication Objects. Since we are not opting for a specific ap-plication, we developed a simple application process to con-trol and perform our experiments. These Upper Layer (UL)is located above the NWK layer. We have implemented theUL as a Contiki process that works independently from therest of the system. The UL uses available stack functionsthat notify the UL of events such as incoming frames. TheUL process is blocked until a packet arrives, or an incomingframe wakes up the UL. The UL then processes the receivedinformation.The ZigBee NWK layer controls the IEEE 802.15.4 MAClayer and provides a service interface to the application layer.The network services include the generation of frames totransport the application layer protocol data units to an ap-propriate device, either the final destination or the next stepin the communication chain. The network layer also controlsa number of network management tasks, such as establishingnew networks, joining and leaving networks, and neighborand route discoveries.We have implemented the NWK layer as a set of func-tions that manage the routing information and other network layer data. The network layer information is stored in threedifferent tables: the neighbor table, the routing table, and theroute discovery table. The three tables are implemented asarrays with a fixed number of elements.
3.2 Adding X-MAC to ZigBee
The IEEE 802.15.4 MAC layer implements a set of MAC-protocol functions and controls the physical layer and guar-anteed time slot mechanisms. The IEEE standard includestwo options for channel access: a beacon-based method, anda CSMA-CA channel access mechanism. We focus on thelatter and therefore our IEEE 802.15.4 MAC layer handlesframe generation, recovery, and acknowledgment control.In state-of-the-art low-power sensor network hardware,the radio device has the highest power consumption [9].Since the MAC layer controls the PHY, most power-savingmechanisms for sensor networks focus on the MAC layer. Toincrease ZigBee network lifetime, we add X-MAC into theZigBee stack, placing it between the IEEE 802.15.4 MACand the radio driver.Our X-MAC implementation consists of three main func-tions that define the protocol operations:
, and
. The
functions are called from theNWK layer. The
function implements the dutycycling of the radio by periodically switching the radio onand off. The operation of the
function is shownin Figure 2. The
function does not control thetransmission or reception of data, but only switches the radioon and off.To be compatible with standard ZigBee implementations,the X-MAC strobe packets must conform to the 802.15.4MAC format. X-MAC unicast strobe packets include theaddress of the receiver. We use the Frame type field of theframe controlfieldintheIEEE802.15.4 MACheader tosep-arate strobe packets from data packets. The frame field cur-rently only uses four of the eight possible packet types: DataFrame, ACK Frame, Command Frame, and Beacon Frame.We define a new frame type, Preamble Frame, for the X-MAC strobe packets. While this solution is not compliantwith the current 802.15.4 standard, it is easy to integrate intofuture versions of the standard.The CC2420 radio, used on our Tmote Sky boards, auto-matically creates packets that conform to the 802.15.4 PHY,and adds the the checksum footer field, the frame length fieldand the a synchronization header field from the 802.15.4MAC.
4 Evaluation
We use the energy estimation features in Contiki [5] toexperimentally quantify the energy-efficiency of X-MAC forZigBee on a set of Tmote Sky nodes. We compare the per-
while(1) {if(we_are_sending) {PT_WAIT_UNTIL(!we_are_sending);}radio->off();set_timer(xmac_off_timer);PT_WAIT_UNTIL(timer_expires(xmac_off_timer));if(we_are_sending) {PT_WAIT_UNTIL(!we_are_sending);}radio->on();set_timer(xmac_on_timer);PT_WAIT_UNTIL(timer_expires(xmac_on_timer));}
Figure 2. X-MAC powercycle basic scheme.
0204060801000.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2
   P  o  w  e  r   (  m   W   )
Data rate (packets/second)NULLMACX-MAC 20%X-MAC 10%X-MAC 5%0204060801000.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2
   P  o  w  e  r   (  m   W   )
Data rate (packets/second)NULLMACX-MAC 20%X-MAC 10%X-MAC 5%
Figure 3. The radio listen power consumption for boththe sender (left) and the receiver (right) increases withdata rate.
formance of X-MAC with the always-on MAC protocol inContiki, called NULLMAC. As expected, the power con-sumption for a node using NULLMAC is high, and batterylifetime is only around four days. NULLMAC is very sim-ilar to the CSMA-CA protocol in the ZigBee specification,which is the only available option for mesh networking inthe current ZigBee standard. We performed our experimentsindoors, inside the SICS office building.We evaluate the energy-efficiency of X-MAC in both asingle-hop scenario and a multi-hop scenario. In the single-hop scenario, we quantify the effect of contention on powerconsumption. Our experiments show that X-MAC decreasespower consumption with up to 90%, that contention in-creases the power consumption slightly, and that, in a multi-hop scenario, power consumption is higher closer to the sink.
4.1 Single-hop Energy Consumption
Before quantifying the energy consumption of X-MAC ina multi-hop scenario, we first measure the energy consump-tion in a two-node scenario. This scenario gives us a baselinemetric, that we can view as a lower bound on the energy con-sumption of X-MAC for ZigBee.In this experiment, one sender sends packets to a sink. Wevary the rate of the data generated by the sender. The datapackets consist of 100 bytes ZigBee payload and a 802.15.4header that includes 802.15.4 addresses in long format. Thetotal packet length is 128 bytes.To compare the energy consumption of X-MAC with thedefault energy consumption of ZigBee, we perform experi-ments with both the 100% duty cycle NULLMAC protocoland X-MAC. We vary the both the data rate and the X-MACduty cycle, between 20%, 10% and 5%.Figure 3 shows the radio listen power consumption with
00.511.522.53NULLMACX-MAC 20%X-MAC 10%X-MAC 5%
   T  r  a  n  s  m   i  s  s   i  o  n  e  n  e  r  g  y  p  e  r   f  r  a  m  e   (  m   J   )
MAC layer configurationTotal transmission energyEnergy for preamble
Figure 4. The energy consumption of the transmission of the preamble increases with decreasing duty cycle. 20%X-MAC 10%X-MAC 5%
   A  v  e  r  a  g  e  r  o  u  n   d  -   t  r   i  p   t   i  m  e   (  s   )
MAC layer configuration
Figure 5. The average round-trip time increases with de-creasing duty cycle.
varying data rate for both the sending and the receiving node,and Figure 4 shows the transmission energy per frame withincreasing duty cycle. The radio listen power consumptionincreases with increasing traffic load. XMAC’s transmissionprocedure requires that strobe packets are sent before theactual packet is transmitted. Hence, the sender must, aftersending each of these preamble packets, turn the radio on inorder to detect the strobe acknowledgment that signals thatthe receiver has detected the sender transmission and that itis ready to receive the packet. Therefore, both transmissionand reception are sensitive to the traffic load of the network.Figure 4 shows that the transmission energy per frameincreases with decreasing duty cycle. The reason for theincrease is that more strobe packets need to be transmit-ted when the receiving node has its radio switched off fora longer time.Note also that a low duty cycle can decrease the perfor-mance because of the longer preamble sequence that is re-quired as shown in Figure 4. If the network load is low, thisis compensated by the energy savings achieved by turningoff the radio for a long time. If the traffic load increases, theenergy consumption is obviously affected.As shown in Figure 5, the round-trip time is affected bythe duty cycle scheme but not by the traffic load. Sincethere are no collision problems in this single-hop scenario,the transmission mechanism should take the same time onaverage with the same duty cycle.
4.2 The Effect of Contention
To study the effect of contention on the energy consump-tion of X-MAC, we use an experimental setup with twosenders that transmit packets to a sink node. Our hypoth-esis is that collisions reduce the power-saving ability whenseveral nodes try to access the channel.According to the original X-MAC design by Buettner

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->