2009:002 civ master's thesis

2009:002 CIV

M A S T E R ' S T H E S I S

Feasibility Study of Formal Analysisof MAC Protocols for

Wireless Sensor Networks

Laurynas Riliskis

Luleå University of Technology

MSc Programmes in Engineering Computer Science and Engineering

Department of Computer Science and Electrical EngineeringDivision of Computer Communication

2009:002 CIV - ISSN: 1402-1617 - ISRN: LTU-EX--09/002--SE

Feasibility Study of Formal Analysis of MAC

Protocols for Wireless Sensor Networks.

Laurynas Riliskis

January 13, 2009

Lule̊a University of Technology Riliskis, L.

ii

Contents

1 Introduction 1

1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Related Work 9

2.1 Performance Requirements . . . . . . . . . . . . . . . . . . . 10

2.2 An overview of selected MAC protocols . . . . . . . . . . . . 12

3 Composable MACs 19

3.1 Abstraction of States in MAC protocol for WSN . . . . . . . 21

3.2 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2.1 Primitive Components . . . . . . . . . . . . . . . . . . 26

3.2.2 Logical Components . . . . . . . . . . . . . . . . . . . 28

3.3 Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4 Formalization 37


4.1 Primitive Components . . . . . . . . . . . . . . . . . . . . . . 40

4.2 Logical Components . . . . . . . . . . . . . . . . . . . . . . . 42

4.3 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5 Summary and Conclusions 49

5.1 Summary and Results . . . . . . . . . . . . . . . . . . . . . . 49

5.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6 Appendices 51

List of Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . 54

List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Notations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

iv

Acknowledgements

I want to express my deepest gratitude to my supervisor Assistant ProfessorEvgeny Osipov. Your encouragement, support and our countless discussionsmade my job easier, thank you.Last, but most important I am deeply indebted to my wife Christina forbearing with me during months of writing, hoping, grumbling and workinglong days.


vi

Abstract

During the last decade the research on sensors have exploded. Starting fromsensors with only few hours of life time until today they have evolved to smallwireless ones, with many years of life time. Introducing wireless communica-tion capabilities to sensor nodes has added a lot of challenges. Shrinking sizeof the sensor requires transceivers to be extremely small. Even with smallradio devices transmitting data over wireless medium is energy consuming.To prolong the life time of the sensor many attempts have been made tominimize energy usage of transceivers. A successful approach is to duty-cycle transceivers. The radio device is shut down during the period that notransmissions are ongoing. However active transceivers that can wake-up onthe transmission have not been developed yet. Therefore a lot of researchhas been focused on the MAC protocol for wireless sensor network, WSN.With an ideal MAC protocol the transceiver should only be on when thereis an ongoing transmission. Nevertheless this is an ideal scenario and due tomedium unreliability, synchronization issues and distributed nature of WSNis not possible yet. Researchers have developed a lot of MAC protocols andmany of them are mostly applicable for specific scenarios, others are moregeneral. The variety of the MAC protocols poses a challenge for the de-veloper of the applications for WSN. The developers have to analyze theprotocols and make a decision on which one to choose. This is not a sim-ple task because the MAC protocol can be available in pseudo code format,written in C/C++ or other language. The creator of the protocol may haveoptimized code making it hard to read and most importantly to compare toother MAC protocols. The test scenario may be slightly different from thedevelopers setup. The question addressed in this Master Thesis is how doyou choose the proper MAC protocol? In this thesis we work on developing aformal method for describing the MAC protocol. Using components we candescribe and analyze the MAC protocol in a simple way. We can comparethe desired metrics such as delay and energy consumption of different pro-tocols. The positive side effect is that components can be reused in differentMAC protocols therefore allowing rapid development of new protocols andoptimize existing ones for the specific situation.


viii

Chapter 1

Introduction

1.1 Background

The military have played an important role in sensor network development.During the Cold War the US government developed acoustic sensors forsubmarine surveillance. Later on, development continued with building theair defense systems with radar. Military sponsored research projects madesolid progress in the sensor area [20].

In the early 1980’s the military started to research if TCP/IP protocols de-veloped for the Internet could be used in the context of sensor networks [20].The aim was to postulate the existence of low-cost distributed sensor net-works that were designed to operate in a collaborative manner, yet be au-tonomous. Other research focused on signal processing, distributed com-puting, tracing and self-location. This leads to commercialization of thesensors and manufacturing them for the military; and the first generation ofthe commercial products was born.

Advances in the sensor research area made in the late 1990’s and early 2000’sresulted in a new generation of sensor network technologies. Sensors weremuch smaller, had integrated sensing, networking and processing. Thesenodes could be used with different network topologies and had a batterylifetime from days to weeks.

With research progress growing exponentially, tremendous developments hasbeen accomplished. Nowadays sensor nodes are from a few grams down to


a dust particle in size (Smart Dust [19, 22]). Some nodes are equipped witha fully integrated sensing, processing and wired and wireless networking.Nodes can be rechargeable using solar energy and having a battery lifetimefrom months to years [20].

Wireless Networking have been available since the late 1960’s early 1970’s,but it took several decades before it started to enter into sensor networks.Mainly because of the many challenges that researchers had to deal with.Firstly the size of the radio device had to be reduced to fit shrinking sensors.Secondly: medium access through radio is power hungry, therefore energyconsumption had to be dealt with. The last challenge has gotten a big por-tion of researcher interest and attention. Many MAC protocols have beenproposed in attempts to minimize power consumption while enabling robustand reliable networking.

There are many applications of the sensor networks and wireless networkingenables even more. Some examples of applications ares are listed below [20].

Military domain:

• monitoring hostile as well as friendly forces;

• chemical, nuclear, biological attack detection;

• and more.

Civil domain:

• Environmental:

– surveillance and research of microclimates;

– agriculture fire or flood detection.

• Health:

– monitoring physiological health;

– tracing doctors and patients inside hospitals;

– drug administration.

• Home applications:

– home automation;

2


– instrument environment.

• Commercial:

– inventory control;

– vehicle tracing and detection;

– traffic flow surveillance;

– environment control in farming.

The wide range of the usage area for the Wireless Sensor Networks (WSN)is growing rapidly. Only the imagination can set the limit for future use ofwireless sensor networks. Before WSN can expand even more much workhas to be done. One of the most important issues is reliable, low power, andsecure wireless communication. Therefore much of the research in the WSNarea focuses on energy saving and wireless communication.

3


1.2 Problem Statement

Wireless Sensor Networks have a bright future in the industrial and homeenvironments. Successes in the last decade of research have shown manyareas of usage [10, 20].

Development of the sensor applications is a multi disciplinary work task.Developers have to hold a good knowledge in wireless network communica-tions and sensor hardware. Human, environment and actuator interactionhave to be designed and put into contextual usage. This makes developingeven small applications hard. Having abstractions and tools for automati-sations would allow focusing research and development toward the actualapplications.

Today, the hardware abstraction is pretty good. Wireless sensors applica-tions developers can choose from several existing and well developed oper-ative systems (OS) for sensors. Most known and actually becoming a defacto standard [10] for sensor networks is TinyOS [3].

The existence of such a OS minimizes the need for the developers to concernabout hardware and allows for the developing of cross platform applications.However, the developer must take into great account network communica-tions even at such low level as MAC. This is due to the nature of wirelesssensors networks. The most energy consuming part in the wireless sensor isthe radio device. Hence we want to optimize its usage in order to prolonglife time of the sensor.

Only the MAC protocol should have direct access to the radio device, there-fore developers have to design each stack. This has resulted in numerousof different MAC protocols designed and optimized for specific applications.Many general MAC protocols are bottlenecks in sensor applications.

Having a framework and tools for rapidly building the MAC protocol wouldmake a great impact on application research area for WSNs. Assume that itwould be enough to specify the set of requirements and constrains in orderto get a near optimal MAC protocol for the specific application, more ap-plications could be tested, developed and researched on. Therefore allowingfocusing on context, usage areas and utilizing many of the ideas that exists.

4


In this thesis we seek a way to building a framework allowing for analysesand composition of the MAC protocols. The first thing to deal with is devel-opment of a formal method in which the MAC protocols can be described.Further, we need the ability to analyze protocols for a set of different met-rics. Metrics are, but not limited to, delay for the message in the MACprotocol and energy consumption for it.

5


1.3 Method

The main goal is to propose a framework for analyzing and comparing MACprotocols for Wireless Sensor Networks. Therefore I started by examining aset of existing MAC protocols. After that the requirements for MAC proto-col were examined, main challenges reviewed and summarized.

It was clear from the beginning that on some level of abstraction MAC pro-tocols can be described in an easy comparable way. Therefore the idea isfirstly to find these common states of the MAC. Secondly decompose MACprotocols to a set of components. This would allow describing different MACprotocols in a formal, analyzable way.

After decomposition we defined a finite set of reusable components. We de-scribed a method to composition components into functional MAC protocol.

The pre and post conditions were defined for components to insure thatintegrity of the MAC protocol could be verified. Components were math-ematically modeled. The formal method for analyses and comparison wastested.

This thesis ends with the summary and conclusions chapter. Results arediscussed and future work is proposed.

6


1.4 Outline

The thesis is organized as follows.

Related work is in Chapter 2. Components and method of composition isdescribed in Chapter 3. Further follows Formalization in Chapter 4, wherewe describe a method for the analyses of the proposed composition. Thethesis ends with a summary, my conclusions and ideas for future work inChapter 5.

7


8

Chapter 2

Related Work

MAC protocols can be grouped into two categories. The first one is cen-tralized MAC protocols. These protocols assume the existence of a node,which have the responsibility to coordinate node synchronization and con-duct transmissions for example the IEEE 802.15.4 MAC protocol for ZigBeenetworks. The other type is decentralized and nodes are responsible only fortheir own synchronization. However, all MAC protocols for Wireless SensorNetwork are driven by the same set of performance requirements, indepen-dently of whether they are centralized or de-centralized.

Further, MAC protocols can be categorized by the type of medium access.For example CSMA, TDMA, CDMA and FDMA.


2.1 Performance Requirements

MAC protocols for WSN have to address at least seven [5, 7, 20] performancerequirements. In this section those requirements and their impact on MACprotocol are discussed.

Delay is the amount of time that a single packet spends in MAC protocol.Delay can by categorized in two types deterministic - which guaranties andensures a predictable number of state transitions and gives the upper boundfor access time; probabilistic on the other hand have expected value, varianceand confidence interval, thus allowing only an approximation of the delay,but gives the possibility to calculate relative worst or best case bound. Delayconcern requires MAC protocols to be simple and have as fewer mechanismsas possible. The designer have to compromise on simplicity and low delaywith the error control, retransmissions and collision avoidance.

Throughput is defined by the rate at which messages are served. Thethroughput can be measured in messages or symbols per seconds but mostcommonly is measured in bits per second. The goal is to maximize it.

Robustness is often referred to as a composition of reliability, availabilityand dependability. It describes protocol sensibility for traffic load over asustained period of time.

Stability describes how good the protocol handles fluctuation of trafficload over a sustainable period of time.

Scalability describes the ability of the communication system to meetperformance characteristics despite of the size of the network and numberof competing nodes. Although this metric belongs more to the networksarchitecture the designer of a MAC protocol has to consider how to han-dle competition for channel access, retransmission and what happens if thetraffic load increases because of the increase of the number nodes.

Fairness A MAC protocol is considered fair if it allocates a channel amongthe competing nodes according to some fairness criteria. However, fairnessis a complex term in WSN. WSN can be viewed as a distributed system and

10


envisaging it so the ratio of channel allocation between nodes may or maynot be a fairness factor.

Energy Efficiency is the most important performance requirement forMAC protocols for WSN. Most of the nodes are deployed with batteriesand have limited life time, hence prolonging life time is a high priority. Itis important for MAC protocols to deal along all the operations with theenergy wast factors [5, 20] and try to minimize it. In the remaining part ofthis section we discuss the six most important energy wasters.

Collisions, When packet collision occurs the node has to retransmit thepacket. This will require a new session of link establishment between nodesand energy for retransmitting the packet.

Overhearing, In order to establish a connection WiseMAC [6] or B-MAC [16]uses long preamble sequences, therefore surrounding nodes will listen to theend of the message that may or may not be addressed to them. Hence thenode who have no interest in the information will receive it anyway. Andthe reception will consume energy power.

Control packet overhead, When designing a MAC protocol one should keepthe number of control packets to a minimum. Otherwise this overhead willresult in unnecessary energy consumption while transmitting and receiving.

Idle listen, While being in idle state with the radio on the node wastesenergy. Therefore many MAC protocols for WSN use some kind of synchro-nization of the sleep schedules or other techniques in attempt to minimizeidle listening. The goal is to have the transceiver off, as much as possible.

Overemitting, Occurs when the node sends a message, data packet, but thereceiving node is not ready to receive it. Hence the node will have to re-transmit it and this increases energy consumption per delivered packet.

Frequent Switching, Between different operation can result in significant en-ergy lost. For example, by minimizing the number of transition betweensleep and awake states of the node, energy can be saved [20].

11


2.2 An overview of selected MAC protocols

The main interest of this thesis lies in the algorithms of the protocols. Inthis section we overview some of the MAC protocols, especially their algo-rithms. Curious readers can discover detailed information, motivation andtest results of protocols in the referred papers.

S-MAC [25] reduces the listening time using periodic sleep schedule, dutycycle. During sleep state the node turns its radio off. A timer interrupt isscheduled according to the duty cycle. When it fires, the node awakes andturns the radio on. The listen interval is fixed on bases of the physicallayer and MAC-layer parameters, like contentions window size. All nodesare free to choose their own sleeping schedule. To enable communication,nodes exchange their sleeping schedule with their immediate neighbors byperiodically broadcasting a SYNC packet. The SYNC packet contains theaddress of the sender node and its sleep time. Sleep time is relative to themoment that sender starts transmission. This technique prevents long-termclock drift. S-MAC includes virtual and physical carrier sense, PCS, and theRTS/CTS exchange. Virtual carrier sense, VCS, is done by looking up localtable with sleep schedules of the neighbors. The medium is determined tobe free if both VCS and PCS indicate that it is free. The node divides thelistening period into two parts, first one for the SYNC packet and next fordata packets. Each part has a contention window with many time slots forsender to perform carrier sense, CS. During the SYNC time period collisioncan occur and the node can miss schedule exchange of its neighbors. Hencethe node will perform neighbor discovery with the frequency depending onthe number of neighbors it has. S-MAC proposes the adaptive listening tech-nique. The basic idea is to let node who overhears its neighbor’s transitionto wake up a short time at the end of the transition. Subsequently it wouldimprove the latency because node is already awake and ready to retransmitif necessary.

T-MAC [24] protocol is based upon the S-MAC protocol but introducesan adaptive duty cycle by dynamically ending the listen period when noactivation event has occurred for a time threshold TA. The basic idea of theT-MAC protocol is to reduce idle listening by transmitting all messages in aburst. Nodes communicates with a RTS/CTS/DATA/ACK scheme, whichprovides reliable transmissions and collision avoidance.

Activation events in the T-MAC protocol are the firing of a periodic frame

12


timer; reception of any data on the radio; the end-of-transmission of a nodesown data packet or ACK; the knowledge from the overhearing; neighborending the data exchange. The T-MAC protocol scheme moves all commu-nications to the beginning of the frame, thus messages are buffered betweenactive times. Upper bound time for the frame is determined by the capacityof the buffer.Authors expect a contention for the medium because messages are transmit-ted in bursts at the beginning of the frame. Therefore increasing contentionwindow is not useful in this case. Hence T-MAC starts RTS transmissionsby waiting and listening for a random time within a fixed contention inter-val, CI. If node does not receive CTS it retransmits RTS two more timesand if no CTS was received node goes to sleep.To avoid early sleeping problem the lower limit on the length of TA is cal-culated: TA > lengthCI + lenght(RTS) + Tturn−around

Overhearing avoidance is similar to S-MAC but in T-MAC it is optional.

DS-MAC [12] takes its foundation in S-MAC, thus if not otherwise writ-ten, DS-MAC behaves as S-MAC [25]. The protocol is motivated by thequestion of ”to sleep or not to sleep”. DS-MAC implements a dynamicallychangeable sleeping interval with fixed length listen period. Therefore theduty-cycle is adjusted to meet changing traffic requirements.

To deal with the clock drift DS-MAC organizes nodes into groups of peerswhich exchanges SYNC packets. Each node maintains a synchronization ta-ble for its neighbors. Whenever it hears a new SYNC packet it will updateits timer accordingly to the one in the SYNC originator. SYNC packetsadditionally contain a new field indicating sender nodes duty cycle.

Each receiver node keeps track of its energy consumption, efficiency andaverage latency. Average latency is defined as the average of packet delayin MAC, in the current SYNC period. From the start all nodes have thesame duty cycle, but when latency becomes intolerable the node shortensits sleep period by half, without changing the listening period, doubles dutycycle. The receiver of SYNC packet checks his queue for packets to SYNCinitiator. In the case of existence of such packets the node will doublehis duty cycle, but only if it’s duty cycle is lower than one in the SYNCpacket. Additional requirement for doubling the duty cycle is that the powerconsumption is below the threshold TE . TE indicates the upper bound ofthe energy consumption level. An important property is that duty cycle isdoubled or halved, thus the neighboring nodes with smaller duty cycle still

13


can communicate with nodes that have doubled their duty cycle. Suggestedduty cycles are 10%, 20%, 40%.

PMAC [26] is a protocol that adaptively determines the sleep-awakeschedules for a node. It is based on its own traffic and the traffic pattern ofits neighbors. Using the patterns received from its neighbors, the node de-cides when to enter a long sleep period. The sleep-wake up pattern indicatesintended sleep-wake up plan. The pattern is represented as binary stringwhere 0 represents intention to sleep and 1 intention to be awake during atime slot. Keep in mind that this pattern is only tentative and is subjectto change. Sleep-wake up schedule is a string of bits representing the ac-tual sleep-wake up plan. Generation of schedules and patterns imitates theslow-start algorithm used in TCP [11].

Pattern exchange is done as follows: the time is divided into frames calledSuper Time Frames, STF. The STF is also divided into frames which arecalled Pattern Repeat Time Frame, PRTF, and Pattern Exchange TimeFrame, PETF. During PRTF , the node repeats its current pattern, thisframe is divided into N time slots with duration TR each, plus additionaltime slot w during which all nodes are awake. This time slot w is usedto prevent long delays when activity along the nodes is low and they havelong sleep patterns, or for broadcasting. PETF is divided into time slots ofduration TE . The last generated patterns becomes the pattern used duringnext PRTF and will be advised during PETF . TR is set to be long enoughto handle contention window plus RTS/CTS/DATA/ACK transmission. Ndepends on the application, the number of TE in PETF is set to the max-imum number of neighbors the node could have and the span of it is longenough to broadcast a pattern.

The actual sleep-wake up schedule is generated using the knowledge of trafficpatterns of node neighbors and the state of the buffer, i.e. whether there isa packet to transmit or not.

TRAMA [18] is a TDMA based algorithm. It is a classic MAC protocoland utilizes in an energy-efficient way. Time is divided into random-accesand scheduled access. In Random-access it establishes two-hop topology in-formation. Channel access is contention based. TRAMA assumes that MACcan calculate needed transmission duration based on the information fromapplication layer. During scheduled access, the node announces the slots itwill use as well as intended receivers. Intended receivers are calculated from

14


bit-maps corresponding to two-hop neighbors. Priority is calculated withhash functions and slot identities.

FLAMA [17] is a scheduling based MAC protocol. FLAMA uses pre-dictability or traffic flow in the networks. It gathers traffic information byallowing the application to specify the traffic characteristics, or uses trafficpredictions in each node. Further, FLAMA uses that information when de-termining schedules, and time when nodes should receive or turn radio off.The three main features of the FLAMA protocol are as follows1)based on two-hop neighborhood information and implicit traffic infor-mation, the node maintains a distributed schedule which is claimed to beenergy-efficient and collision-free;2)the communications between nodes with limiting processing and storagerequirement performs with low transmission delay;3)protocol is robust even with changing topology.

The showcase in [17] is customized for data gathering applications.

wiseMAC [6] is a one channel non-persistent CSMA with preamble MACprotocol. All nodes listen to the medium with common periods, but relativeschedules are independent. If a node wakes up and the medium is busy it willlisten until packet is received or medium becomes idle. Initially the pream-ble size is the sampling period. WiseMAC does not use any handshakingtechnique. WiseMAC dynamically decides the length of the preamble. Thedecision is based upon knowledge of the sleep schedules for the transmittingneighbors. Nodes learn and refresh neighbors sleep schedule during everydata exchange. This information is stored in a table. Transmissions arescheduled so that the destination nodes sampling time equals half of senderspreamble.

B-MAC [16] is based upon CSMA with preamble. When a node has amessage to send, it first transmits a long preamble followed by the message.The time duration when the preamble is transmitted is long enough to coverthe time nodes is sleeping. When the node hears the preamble it will waitto the end and then receive the message. Then the message reception isacknowledged by sending an ACK.

X-MAC [2] is built upon a class of asynchronous duty-cycled MAC pro-tocols. Actually it is an improvement of the B-MAC protocol. The protocol

15


is designed to address the number of problems in order to improve perfor-mance and reduce energy waste of the MAC protocol discussed on page 11.The following problems are particularly addressed: overhearing, excessivepreamble and incompatibility with packetizing radios.

X-MAC tackles the overhearing problem by dividing the usual long pream-ble packet into a series of short ones and including the targeted receiverID. During the synchronization stage the sender transmits a short preamblepacket and listens for a short period of time for the acknowledgment. Theperiod during which the transmitting node sends a preamble packet has tobe greater than the maximum length of the receivers sleep period.

When the receiving node wakes up and receives the preamble packet, itchecks for an ID. If the ID does not match the node’s ID then it immedi-ately returns to sleep, otherwise the node will send an early acknowledgment(EACK) and stays awake to receive the subsequent data packet. After thereception of the intended data packet the node stays awake for the periodof time equal to the maximum duration of back-off time in case there isanother node wanting to transmit.

If the transmitter is about to send and detects the ongoing preamble, thenode will listen to the channel for the EACK. If the node overhears theEACK with the intended receiver ID, then the node will back-off for a ran-dom amount of time and transmit data without preamble. Otherwise, it willstart with the preamble. The back-off time has to be long enough to allowthe initial transmitter to complete its data transmission.

X-MAC for ZigBee Remarker, Suarez, Dunkel and Voigt describe [21]an implementation of X-MAC in ZigBee based WSN. The main differencefrom the ZigBee standard [9] MAC is that the proposed X-MAC implementa-tion does not assume that routing nodes have a constant power supply. ThisX-MAC implementation makes ZigBee useful for a new class of applications.

The differences from the original X-MAC [2] are strobe packets are con-formed to IEEE 802.15.4 MAC format. It consist of three main functionssend, read and power cycle. This implementation adds a new frame type,Preamble Frame, for the X-MAC strobe packets.

16


MFP-MAC [1] or Micro-Frame Preamble MAC. To avoid irrelevantdata reception MFP-MAC replaces continuous preamble by a series of smallframes. Each frame contains an indicator of the data frame content, suchas destination address and a hash if the data field. This allows the node toestimate the time needed for the actual data transmission and sleep untilthen. The node can switch off the radio if it finds out that the data to betransmitted is irrelevant. The node is able to estimate the time when thewhole transmission ends and wakes up only at the end.

The frames are numbered from 1 to m, where m is the amount of micro-frames needed so that their transmission lasts at most the check interval Tw.This number is included in the Micro-frame. When the nodes share the samecheck interval, m is the same for all nodes. Hence when a micro-frame isreceived the node can estimate the time for the arrival of the data and forhow long it can sleep. Nodes keep a table with hash-data, sent in the micro-frame, therefore minimizing redundant reception. The authors eliminatespossibilities of hash collisions because of the fact that the table is clearedafter each timeout. The authors do not expect a lot of simultaneously activebroadcasts and expect that a hash function has good properties.

17


18

Chapter 3

Composable MACs

Studying states of the MAC protocol for WSN gives an opportunity to iden-tify the common parts of MAC and the relations between them. From theMACs summarized in Section 2.2 we can decompose and describe them ina formal way.

This gives us an opportunity to study the way different components of aMAC protocol influence the global performance of it. Likewise how chang-ing these small blocks can help to better meet performance and applicationrequirements.

To achieve this goal the Top-Down approach is used to begin with. Thisapproach is motivated by the need to identify the behavior in higher order ofthe MAC protocol. When the higher order states are identified we can useBottom-Up design. With Bottom-Up approach we can adjust the behaviorof states in more precise details. Approaching from both side results in arobust design, where detailed state behavior can easily be modified withoutchanging the inter-state behavior.

To describe MAC protocols we use components. The idea is to model theMAC protocol based on the same components but using different parame-ters. We test this idea with CSMA-preamble based protocols. The choiceof this medium access method is due to the popularity and simplicity ofthem. This approach will work on other type of MAC protocols, like TDMA,CDMA or FDMA.


We contemplate all components as reactive components. The idea is that acomponent maintains its state and reacts on the external events. This meansthat inter-component communication between reactive components is doneby asynchronous message passing. Therefore many of the components havefeedback sockets. This allows easy callback implementation without haltingthe process.

It is not coincident that we envisage components as reactive. Componentsand reactive object have been researched and are used successfully in real-time systems. TinyOS [3] is one example of an event driven operating systemfor sensor nodes. TinyOS is component based; these components are wiredtogether to an application. Components react on events and can make callsto other components. Timber [14] is a promising programming languagethat implements and advocate reactive objects [15].

We adopt this view and describe MAC protocols with reactive components.With the reactive components we describe what is done, with which com-ponents and how they interact. The implementation describe how it isdone.

For further discussion we need to clarify what we mean by parameter,therefore we detail a general definition of it.

Definition 1. Parameters are only those arguments that affects perfor-mance and behavior of the component.

The parametrization of components allows us to analyze the performance ofthe MAC protocol in terms of energy usage and delay. The metrics are notlimited by this technique to energy and delay. But this thesis concentratesonly on them, leaving the rest for future work.

We discuss components and composition of them further in this chapter. Thechapter ends with two examples of well known MAC protocols described indescribed using our framework.

20


3.1 Abstraction of States in MAC protocol for WSN

The primary task of the MAC protocol is, given the message from the higherlayer, to transmit it to the given destination node. Applying the require-ments, discussed in Section 2.1, general states can be extracted. The mostdiscussed issue concerning the MAC protocol is energy saving [4, 5, 7, 13, 20].Therefore, knowing that the transceiver is the most energy consuming partof the wireless sensor node, we want to minimize the time when the radio ison. The time during which the MAC protocol is idle needs to be minimizedwhile keeping a high throughput and a low delay. Furthermore, the MACprotocol has to be able to establish a channel link between nodes and doso without interfering with other ongoing communications. We narrow theessential states down to: sleep, listen, send, channel access, transmit andreceive.

Further in this section we discuss each state in more detail. We describe es-sential states and transitions between them and illustrate it with simplifiedState Machine in Figure 3.1.

Sleep is the state of the MAC protocol when the radio is off.

Listen is the first state that the MAC protocol enters on wakeup. Theradio is turned on and MAC can send and receive messages. Hence it is astate from which MAC can progress to other states such as channel access,transmit and receive.

Send. In this state the MAC protocol is ready to transmit. Before thetransmission of the actual message, the node has to establish a link to thedestination node. When the link is established the message is transmitted.

Channel Access is the state in which the node synchronizes with thedestination node for the transmission or performs clock synchronization,sleep-schedule exchange or other operations in order to maintain connectiv-ity to neighboring nodes. If the MAC protocol is CSMA based then the nodewill synchronize using preamble. If it is TDMA based it may use RTS/CTSexchange or it will synchronize to internal tables and exchange their sleepschedules with neighbors.

21


Figure 3.1: Abstract State Machine of the MAC protocol.

Receive. In this state the MAC protocols waits for data from the PHY.This states sets the radio device into receive mode.

Transmit. In this state the MAC protocol writes data to the hardwarelayer. The radio device is set to transmission mode and bits or a data packetis passed to the hardware layer for transmission.

The State Machine in Figure 3.1 gives the idea that the MAC protocol be-haves in repeated pattern. It transmits some piece of data and waits forfeedback, listens to the channel, when transmits again. Therefore, if weseparate the basic pieces of functionality we can reuse them in a logical wayaccordingly to the algorithm of the MAC protocol.

Consider the general algorithm of the MAC protocol. Before sending a mes-sage to the destination node, a link needs to be established between nodes.Therefore the transmitting node may send channel request. It can bepreamble, RTS/CTS or time synchronization, then the protocol may listen

22


to the channel for feedback. When link is established, the node will transmitthe message received from the higher layer and may listen to the channel forthe feedback. When listening, the MAC protocol will wait for the messagefrom the physical layer. It may receive a time synchronization packet andacknowledge it. Or it may receive preamble, and then data message andacknowledge it by sending feedback.

We find it to be convenient to describe any MAC protocol in a way thatdifferent protocols can be compared and analyzed per component bases.Furthermore, given a set of implemented components we need only changetheir logical structure, re-wire them, to compose different MAC protocols.

23


3.2 Components

In this section components are derived from a set of MAC protocols de-scribed in Section 2.2. Correlations among them are identified and classified.

UML 2 [8] notations will be used as long as possible. However the UML2 notation is not sufficient for reactive-component design and therefore weredefine some of the symbols and introduce new ones. The notations arecollected and described in the Appendix.

Definition 2. A software component is a system element offering a pre-defined functionality, and is able to communicate with other components.

Clemens Szyperski and David Messerschmitt in [23] give the following fivecriteria for what a software component shall be to fulfill the Definition 2.

• Multiple-use;

• Non-context-specific;

• Composable with other components;

• Encapsulated i.e., non-investigable through its interfaces;

• A unit of independent deployment and versioning.

We further categorize the set of components as follows:

• Hardware Component,HC;

• Primitive Component, PC;

• Logical Component, LC.

Hardware Components, HC, are directly dependent on and using hard-ware of the node. For example, the Timer component who uses the internalclock of the node and fires after specified amount of time. Another exampleis the PowerControl component that turns on and off radio transmitter.Hardware components may have a usage cost in metrics such as delay andenergy. For example, the PowerControl have a cost in both time and en-ergy. When turning the radio transmitter on, it has a time delay before the

24


transmitter is ready and in idle mode. This startup has a cost in energy aswell.

Primitive Components have atomic functionality which is reused by othercomponents.

Logical Components have certain behavior over the time and have a de-terministic life time.

25


3.2.1 Primitive Components

We have identified two Primitive Components shown in Figure 3.2. We startthe name of each primitive components with PC followed by the name ofthe component.

• The PC Tx component transmits a structured array of bits. Thecomponent is activated by the send data event. It provides a feedBacksocket. This socket provides information whether the transmission hasbeen successful or not. This information is a structured message andcan be implemented in different ways.

• The PC Rx component receives a structured array of bits. The com-ponent is activated by the receive event. This component is directlyconnected to the radio device and waits a given amount of time fora message to arrive. The component provides a dataOut socket forthe received data. If no data is received during listening, NULL will beprovided.

(a) Transmit: PC-Tx. (b) Receive: PC-Rx.

Figure 3.2: Primitive Components.

The performance of a PC is measured in terms of delay and energy consump-tion. By delay we mean the time components consume while performing agiven task. By the energy consumption we mean the amount of batterypower used to perform the task.

The performance of these components is strongly related to the used hard-ware. Transmission rate influences the delay that PC Tx will result in.This delay and the energy needed to transmit, will affect power consump-tion. The parameter of this component is sizeof(data).

The PC Rx component performance is influenced directly by the receptionrate of the transceiver. The delay induced by receiving a message will result

26


in energy cost.

An important factor is the time and energy it takes for the transceiver tochange its state. This state change takes place in the component, delayand energy consumption is added to component performance. State changefactors applies for both primitive components.

27


3.2.2 Logical Components

A Logical Component (LC) can be composed of several PCs and otherLCs. It represents the logic of the MAC protocol or its submodules. Theconcept of building a LC is shown in Figure 3.3. The arrows describeinter-component communications via asynchronous message passing. Inter-component communications can be synchronous, but it is a good designchoice to keep them to a minimum because synchronous messaging can causedeadlocks and unnecessary lock outs of other tasks. LC uses PCs and LCs indifferent order and logical purpose to achieve the task of the MAC protocol.We add LC in front of the name of the logical component.

Figure 3.3: Example of a Logical Component.

We have identified five Logical Components, who are listed below. We onlyresearched on one type of MAC protocol CSMA with preamble. Thereforethe set of components could be extended for other schemes. However othertype protocols can be described with only small changes in the logical com-ponents and their implementation.

28


In this section we describe and discuss proposed components. But the moreformal description with pre and post conditions will follow in the Formal-ization chapter.

• The LC Handler is a handler component. It deals with feedbackevents generated by components and makes calls to other compo-nents. It can use other LC components and handle feedback fromthem. The lollipop symbol defines an interface of the component. Thesocket means that this component can use another components inter-face. The LC Handler component handles PCs and LCs in time witha given pattern. The pattern defines the logic for the chain of events.LC Handler has a tunit parameter which defines the TTL, time tolive. The TTL defines a time pool for the component. The time poolis only used during active state of the component. It does not includetime that other components activated from it can consume.

Figure 3.4: Logical components of the LC Handler Component.

• The LC Send component provides a dataIn interface and a feedBacksocket. The component is activated when an event of data arrival onthe interface of dataIn occurs. The component provides a feedBacksocket which can be wired for the delivery status notification. Moreabstractly this component is responsible for delivering a given messageto the destination node.

• The LC ChannelManager component is responsible for establishingthe link between next hop nodes. It has an activation interface andfeedBack socket on which channel status is returned. Naturally itslogic resides in the LC Handler component and what PCs it uses.

• The LC SendData component has the task of sending the messageto the destination node. Similarly to the LC Send component, it hasthe msgIn interface and feedBack socket. However, the componentassumes the existence of the established link. Therefore, it sends themessage immediately to the medium and may be followed by the reli-able transmission logic.

29


• LC Listen, is a component that controls the duty cycle of the MACprotocol. This component is responsible for powering the transmitteron and off; receiving messages from the medium and delivering themto the higher layer.

30


3.3 Composition

In this section we discuss the composition of components.

The MAC protocol has two tasks, transmit messages to the medium and re-ceive messages from it. In order to save battery power, the radio device onthe node has to be periodically turned on and off. Hence, periodic wakeupcan be described as a listening component re-scheduling itself with a givenduty cycle. When the event of a message arrival from the physical layer oc-curs, the LC Listen component may acknowledge it and pass it to the layerabove. An example of the LC Listen component is illustrated in Figure 3.5.

Figure 3.5: Detailed view of the LC Listen component.

In case of a message arrival from a higher layer, this component invokesthe LC Send and halts the power down event. When LC Send is invokedit will try to establish a channel link by RTS/CTS handshake, preambleor/and time schedule based approach. When the channel is ready, LC Send

31


will transmit the message. The reason for the LC Listen component to beinvolved when the message arrives from higher layer is simple. We want tolimit the number of components that interact with higher or lower layers.Therefore LC Listen controls radio powering and communications with ahigher layer.

When a message from a higher layer arrives to the MAC protocol it will tryto send it to the destination node. Therefore the LC Send comes into playas a higher order component. A graphical representation is illustrated inFigure 3.6.

Figure 3.6: The LC Send component.

Before initiating the transmission of a message the channel request is per-formed. For this reason we call the LC component that manages this forthe LC ChannelManager, it can be referenced as LC ChM. The tasks for itis, when requested, establish a link with the destination nodes and providefeedback about outcome. The feedback can be, for example, that the link isestablished or not. It can contain a point in time when the transmission canbe performed. It can be the transmission frequency or even a combination ofthem all. This is depending on the actual implementation of the component.

32


When the link is established, the LC Send component is ready to send anactual message to the destination node. This is done from the LC SendDatacomponent. When the message is sent, the LC SendData component mayor may not wait for an ACK and provide further feedback. An example ofa detailed LC Send component is illustrated in Figure 3.7.

Figure 3.7: Detailed view of the LC Send component.

Depending on the algorithm of the MAC protocol, reliability can be builtin, in several places. By reliability we mean assurance that the message isreceived by the destination node. This is done by the re-send mechanism.For example, the LC SendData can have re-transmission pattern, it can bebuilt into the LC Send component.

33


3.4 Example

In this section we decompose the XMAC and BMAC protocols. We describethem in our proposed framework, compare their components and parame-ters. The XMAC and BMAC protocols that uses CSMA and preamble forchannel establishment.

In our example we assume that the receiving node awakes a bit later thanthe sender node. Further we assume that there is no radio interference andtherefore, if the node is awake, it receives data without errors. The protocolsare simplified, no time synchronization is assumed.

If there is a message to transmit, the BMAC protocol will start to send apreamble for time t and then send a message, which is acknowledged by thereceiving node. The time line with activities is shown in Figure 3.8. By tcwwe mean contention window, the time the node spends competing for themedium. ts is the radio startup time and tchm is the time needed to changestate of the transceiver. Gray colored boxes shows reception of data; whitetransmission; dotted white boxes illustrates listening period.

Figure 3.8: Activity time line of the BMAC protocol.

The XMAC protocol is an enhancement of the BMAC protocol. Instead ofsending one long preamble, the XMAC protocol sends a short one with thedestination nodes ID and waits for early acknowledgment. When a nodereceives preamble it will check if its ID matches the one in the preamble. Ifso the node will respond with EACK. If the ID does not match the nodecan go back to sleep during transmission. When EACK is received by thesender node it will transmit the message and go back to sleep. When themessage is received the node will stay awake for a short period of time sothat it can receive data from other nodes.

34


Figure 3.9: Activity time line of the XMAC protocol.

Both the XMAC and BMAC protocols can be described with the same setof components. We realize that the main difference between the XMAC andBMAC protocols is in the usage of preamble and acknowledgment. There-fore, in case of the XMAC protocol we need the PC Rx component in theLC ChannelManager component instead of in the LC SendData component.The rest of components are the same but with different initialization pa-rameters. These are compared in Table 3.1. All of the components can bereused, mostly by just changing timing parameters.

Table 3.1 shows the difference in initialization parameters between the BMACand XMAC protocol. As we see in the LC ChannelMananger component,the BMAC protocol will only transmit once and not initialize the PC Rxcomponent. The XMAC protocl on the other hand will transmit preamble ktimes. Further in the LC SendData component it will be the XMAC proto-col who does not initialize the PC Rx component, but the BMAC protocolgoes.

TransmittingComponent BMAX protocol XMAC protocol

LC ChM {tunit, sizeof(preamble),1}

{tunit, sizeof(preamble),k}

PC Rx {NULL} {tunit}LC SendData {tunit, sizeof(msg), 1} {tunit, sizeof(msg), 1}

PC Rx {tunit} {NULL}

Table 3.1: Parameter comparison between the BMAC and XMAC protocolswhen sending.

35


ReceivingComponent BMAX protocol XMAC protocol

LC Listen {tunit, sizeof(ACK),sizeof(msg)}

{tunit, sizeof(EACK),sizeof(msg)}

Table 3.2: Parameter comparison between the BMAC and XMAC protocolswhen receiving.

In Table 3.2 we have compared the parameters of the LC Listen componentfor the BMAC and XMAC protocols. The difference is when the protocolsreceives the preamble and message. In case of the BMAC protocol it willacknowledge when the message is received. In case of the XMAC protocolthe EACK will be sent after receiving the first preamble strobe.

36

Chapter 4

Formalization

Long life time of sensor nodes is the most important challenge in today’sWSN research. The most power consuming features in a node are the radiotransmission, reception and idling. Therefore it is not accidental that theMAC protocol plays the leading part in energy saving.

It is important to analyze and compare performance and behavior of theMAC protocol when selecting the appropriate one for sensor applications.This need embraces the importance of decompositioning of the MAC proto-col. Decomposition allows identifying the correlations between the compo-nents and their behavior. Their influence on the performance of the MACprotocol can be analyzed. By doing so we can more easily model, analyzeand implement a MAC protocol for a specific sensor application.

The ability to compare MAC protocols fairly requires their formal descrip-tion. Therefore in this chapter we work on the formal method for describingand analyzing MAC protocols for wireless sensor network.

It is important to recognize the difference between our proposed method andknow formal methods as Z, B, SPC, SPCS||B, B-event or other. These meth-ods provide the logical verification of the specifications and prove for somecorrectness using mathematical notations. Among other things, these meth-ods allow to insure the runtime correctness and discover buffer overflows. Inour case we want a formal method for a description of the components,which would allow for the calculations and comparison of the performanceand parameters. In the review of existing formal methods we did not findthat any of these methods would be suited for our task. It could be a task for


future work to try how it is possible to incorporate existing formal methodsinto our work.

Previously discussed components, in particular Primitive Components givesa good start. They are quite simple, both to describe in a mathematical wayand to analyze. We narrow analyzes and formalization down to two metricsdiscussed in Section 3.2.1: delay and energy consumption.

When discussing delay resulted by some components, we write

D(c) =n∑

i=0

f(pi), c ∈ C (4.1)

where c is component and C is set of defined primitive and logical compo-nents. f(p) is a function of the initialization parameter.

Similarly, the energy consumed by the component c, from the set C ofdefined primitives and logical components, is

E(c) =n∑

i=0

f(pi), c ∈ C (4.2)

Furthermore to clarify the component we use pre and post conditions. Thisallows us to deduce assumptions and logical flow between components.

We define the following parameters used in formalization:

Px Power consumed by x, where x ∈{Tx, Rx, S (start up)}.Lx Length of x, where x ∈{pre (preamble), msg (message), EACK, ACK}.tx Time that it takes to perform task x, where x ∈ {cw (contention win-

dow), l (listen), s (start up)}.R The data rate of transmitter.

We have previously discussed the delay and energy consumption when thetransceiver changes state. However, we believe that the resulted delay andused energy are of a magnitude that can be disregarded in our more abstractmodeling.

In the next section the primitive and logical components discussed earlier,

38


are to be formally written. We end this chapter with an example of theanalyses.

39


4.1 Primitive Components

In this section we describe the mathematical model of the Primitive Compo-nents. Since we only concern with CSMA protocols we can define equationswithout abstractions.

The transmit component PC Tx, has one parameter: the size of the messageto transmit. We write the delay resulted by PC Tx component in Equation4.3 and the energy consumed in Equation 4.4.

D(PC Tx) =Ldata

R(4.3)

E(PC Tx) = PTx × (Ldata

R) (4.4)

We define conditions for the PC Tx component:

PC_Tx::pre := {radio == (on && !inUse),data != NULL}post:= {radio == (on && !inUse),

data == (transmitted || error),feedBack != NULL}

We write the receive component PC Rx for delay in Equation 4.5 and forenergy consumption in Equation 4.6.

D(PC Rx) = tl +Ldata

R(4.5)

E(PC Rx) = PRx × (tl +Ldata

R) (4.6)

The receive component has two parameters, the size of the data receivedsizeof(data) and timeout tl. The timeout parameter defines the maximumtime this component will stay active for. Therefore the worst case delayis when the component stays active almost the whole time, tl, and when itstarts to receiving the message. We assume that the component will continueto receive the message in the latest case. Thus the worst time delay is givenby the sum of time needed to receive message and the timeout time.

40


We define conditions for the PC Rx component:

PC_Px::pre := {radio == (on && !inUse), timer == available}post:= {radio == (on && !inUse),dataOut == (data || error)}

41


4.2 Logical Components

The performance of the Logical Components are directly dependent on theused PCs and the pattern of the LC Handler component. Therefore it de-pends on the logic and the implementation. However we state for each ofthe five components, the general expression for the delay and energy perfor-mance. We define pre and post conditions as well.

LC ChannelManager is the component that is responsible for the estab-lishment of the channel between the nodes. Therefore we can state theconditions as follows:

LC_ChannelManager::pre := {radio == (on && !inUse), timer == available}post:= {radio == (on && !inUse),feedback == (link || error)}

We write the performance metrics as for delay: D(LC ChannelManager)and for energy E(LC ChannelManager).

Assuming that the channel is established, the LC SendData componentstakes care of sending a message to the channel. It provides feedback whichcan be ACK, or a notification that the message was sent successfully.

The conditions are:

LC_SendData::pre := {radio == (on && !inUse), timer == available,

link == available, msg != NULL}post:= {radio == (on && !inUse), msg == (sent || error),

feedback != NULL}

We write the performance metrics as for delay D(LC SendData) and forenergy consumption E(LC SendData).

LC Handler is the component where the logic where the chain of the de-fined events. Therefore, it does not result in any delay or energy usage. Thepre and post conditions depend on the pattern i.e. components used.

The LC Send component is a global sending mechanism. It has compo-nents for the channel establishment and for sending actual messages. As

42


well, it controls how acknowledgment of messages works.

The conditions for the component are:

LC_Send::pre := {radio == off, timer == available, msg != NULL}post:= {radio == off, msg == (sent || error),

feedback != NULL}

We write the performance metrics as, for delay D(LC Send) and for energyE(LC Send).

The LC Listen component is in charge of activating the LC Send when themessage arrives from a higher layer. The rest of the time it listens to themedium following a specified patter (duty cycle).

The pre and post conditions for the LC Listen component are:

LC_Listen::pre := {radio != inUse, timer == available}post:= {radio != inUse, feedback != NULL}

We write the performance metrics as, for delay D(LC Listen) and for en-ergy E(LC Listen).

Due the usage of PCs in Logical Components some of the pre and post con-ditions are inherited from PCs to LCs.

Naturally, the equations of the performance expand depending on the actualparameters of the component. Parameters can vary dependently on theprimitive components used and the building logic. We exploited expansionof the equations idea using the example discussed in section 3.4.

43


4.3 Example

Having the foundation from the formal definitions of the PC and LC we cango through the example defined earlier in Section 3.4.

We use the components and initialization parameters defined in Table 3.1for the send message event.

The LC Send component does not has a PC or any other components whoaffect it’s performance. Therefore total cost of transmission is the sum ofcost for the LC ChannelMananger and LC SendData components.

We start with the LC ChannelMananger, LC ChM, component. We for-mally write delay with the Equation 4.7.

D(LC ChM) = k × (D(PC Tx) + D(PC Rx)) (4.7)

Similarly, the energy consumed is given by Equation 4.8.

E(LC ChM) = k × (E(PC Tx) + E(PC Rx)) (4.8)

Now we can write these equations specifically for the BMAC protocol. Equa-tion 4.7 gives the delay in Equation 4.9. The BMAC protocol does not listento the medium during link establishment. Therefore the PC Rx componentis null initialized and is not included into calculations.

D(LC ChM) = tcw +Lpre

R(4.9)

The energy consumption can be expressed from the Equation 4.8 as Equa-tion 4.10.

E(LC ChM) = Pcw + PTx(Lpre

R) (4.10)

For the XMAC protocol, delay is given by Equation 4.11 and energy con-sumption by Equation 4.12.

D(LC ChM) = tcw + k × (Lpre

R+ tl) +

LEACK

R(4.11)

44


E(LC ChM) = Pcw + k × (PTx(Lpre

R) + PRx(tl)) + PRx(

LEACK

R) (4.12)

The last component for the transmission of the message is LC SendData.It is described in Equation 4.13 for the delay and in Equation 4.14 for theenergy consumption.

D(LC SendData) = D(PC Tx) + D(PC Rx) (4.13)

E(LC SendData) = E(PC Tx) + E(PC Rx) (4.14)

Using parametrization in Table 3.1 we can rewrite for the BMAC protocolEquation 4.13 as Equation 4.15 for the delay and Equation 4.14 as Equa-tion 4.16 for the energy consumption.

D(LC SendData) =Lmsg

R+

LACK

R(4.15)

E(LC SendData) = PTx(Lmsg

R) + PRx(

LACK

R)) (4.16)

The XMAC protocol can be written as Equations 4.17 and 4.18 respectivelyfor delay and energy consumption.

D(LC SendData) =Lmsg

R(4.17)

E(LC SendData) = PTx(Lmsg

R) (4.18)

Now that we have derived mathematical models for different componentsused during transmission of the message we can summarize it with a delayand energy consumption models for the BMAC and XMAC protocols sep-arately. For the BMAC protocol we merge Equations 4.9 and 4.15 for thedelay into Equation 4.19.

D(Tx) = tcw +Lpre

R+

Lmsg

R+

LACK

R(4.19)

45


For the energy consumption we merge Equations 4.10 and 4.16 into Equa-tion 4.20.

E(Tx) = Pcw + PTx(Lpre

R+

Lmsg

R) + PRx(

LACK

R) (4.20)

The transmission model can be composed for the XMAC protocol usingEquations 4.11 and 4.17 for the delay into Equation 4.21.

D(Tx) = tcw + k × (Lpre

R+ tl) +

LEACK

R+

Lmsg

R(4.21)

For the energy consumption we merge Equations 4.12 and 4.18 into Equa-tion 4.22.

E(Tx) = Pcw + k × (PTx(Lpre

R) + PRx(tl)) + PRx(

LEACK

R) + PTx(

Lmsg

R)

(4.22)

Contemplating transmission Equation 4.19 of the BMAC and XMAC 4.21protocols we realize that when the clock drift of two nodes goes to zero,the XMAC protocol outperforms the BMAC protocol with a less delay andtherefore less energy consumption. This observation allows developers of theWSN application to make a clear choice regarding which MAC protocol toselect for the application. Even more, the same implementation can be usedonly by changing parameters and some of the logic in the MAC protocolso that both implementations can easily be tested without the double workload implementing each of them.We write the LC Listen component in Equation 4.23.

D(LC Listen) = ts + tl + D(PC Rx)p + D(PC Tx) (4.23)

For the BMAC protocol LC Listen component’s delay is given by the Equa-tion 4.24 and energy consumption by Equation 4.25.

D(LC Listen) = ts + tl +Lpre

R+

Lmsg

R+

LACK

R(4.24)

E(LC Listen) = Ps + PRx(tl +Lpre

R+

Lmsg

R) + PTx(

LACK

R) (4.25)

46


Similarly, we derive the LC Listen component for the XMAC protocol inEquations 4.26 and 4.27 for delay and energy consumption respectively.

D(LC Listen) = ts + tl +Lpre

R+

LEACK

R+

Lmsg

R(4.26)

E(LC Listen) = Ps + PRx(tl +Lpre

R+

Lmsg

R) + PTx(

LEACK

R) (4.27)

The LC Listen component model for the BMAC and the XMAC protocolslooks very similar. We understand that because of the shorter preamble andearly acknowledgment the performance of the LC Listen component e.g. re-ceiving, will always be better for the XMAC protocol. Even in the worstcase scenario, if nodes start to receive the preamble just before it should goto sleep. The small preamble and EACK are much less time consuming inthe XMAC protocol case than in the BMAC protocol case where the pream-ble is at least as long as the duty cycle.

We have formally described and given mathematical models of the BMACand XMAC protocols in this example. With formal description we havebeen able to clearly show in which parts of the MAC protocol the BMACis different from the XMAC protocol. The formal description allows us tomake a qualified guess about which protocol, given a scenario, will performbetter. Given a real node values, we can optimize the parameters so thatthe MAC protocol can perform even better. We get a bonus with this formalmethod because of the components. We can reuse them in several differentprotocols only by modifying parameters and wiring between them. Suchreusability allow not only for rapid development of MAC protocols, it givesan opportunity to test them in a real situation without wasting time onmaking many implementations.

47


48

Chapter 5

Summary and Conclusions

In this Chapter we summarize the work of this thesis. The results of it andfuture work is discussed.

5.1 Summary and Results

In this thesis we have overviewed several MAC protocols for WSN. Theoverview gave an understanding of the behavior of the MAC protocol. Weabstracted the states of the MAC protocol and many of the existing MACprotocols for WSN can fit under it. The analyses of the abstract states re-sulted in derivation of components.

We found that suited categories for the components are hardware, primi-tive, and logical. The component categories were well described. We en-visage components as reactive components. This allows us to use messagepassing idea. The component can be activated by the triggering a anothercomponent event. The same component can make a call back to initiatorby triggering a feedback event. Therefore, the Logical Component that useseither a Primitive Component or another Logical Components, can decideon taking proper action. Hence we can build a logical hierarchy using thesame components by only changing their wiring and parameters.

Additionally we describe a methodology how to wire components into func-tional MAC protocol for WSN. We found that the MAC protocol from thesame medium access class can be described with the same components. The


medium access method that we focused on was CSMA. We do not think thatmethodology is limited to CSMA and may be used with TDMA, FDMAand CDMA protocols. When describing MAC protocols from the same setof medium access we found that the only difference in components are pa-rameters.

Logical Components and parameterization allows us to develop a formalmethod for description of the components. Formally described componentscan be mathematically analyzed. Therefore the algorithmic performance ofthe MAC protocol can be calculated using components. We have shown theexpected performance using calculations.

Formally described components can be individually analyzed. Using someoptimization technique, the parameters can be tweaked for optimal perfor-mance.

5.2 Future Work

During this work we realized that the MAC protocols for the wireless sensornetworks is a hard and extensive area. Therefore, some of the planned workhad to be rationalized away for future work. We see two clear paths forfuture work.

• Verification through implementation and extensive simulations.

• Extension of the components and formal descriptions to address othertypes of MAC protocols.

50

Chapter 6

Appendices


52

List of Abbreviations

ACK . . . . . . . . . . . . AcknowledgmentCI . . . . . . . . . . . . . . . Contention IntervalCPU . . . . . . . . . . . . . Central Processing UnitCS . . . . . . . . . . . . . . . Carrier SenseCTS . . . . . . . . . . . . . Clear To SendEACK . . . . . . . . . . . early AcknowledgmentHC . . . . . . . . . . . . . . Hardware ComponentIEEE . . . . . . . . . . . . Institute of Electrical and Electronics EngineersLC . . . . . . . . . . . . . . Logical ComponentMAC . . . . . . . . . . . . Medium Access ControlOS . . . . . . . . . . . . . . Operating SystemPC . . . . . . . . . . . . . . Primitive ComponentPCS . . . . . . . . . . . . . Physical Carrier SensePETF . . . . . . . . . . . Pattern Exchange Time FramePRTF . . . . . . . . . . . Pattern Repeat Time FrameRTS . . . . . . . . . . . . . Request To SendSTF . . . . . . . . . . . . . Super Time FramesSYNC . . . . . . . . . . . SynchronizationVCS . . . . . . . . . . . . . Virtual Carrier SenseWSN . . . . . . . . . . . . Wireless Sensor Network


54

List of Figures

3.1 Abstract State Machine of the MAC protocol. . . . . . . . . . 22

3.2 Primitive Components. . . . . . . . . . . . . . . . . . . . . . . 26

3.3 Example of a Logical Component. . . . . . . . . . . . . . . . 28

3.4 Logical components of the LC Handler Component. . . . . . 29

3.5 Detailed view of the LC Listen component. . . . . . . . . . . 31

3.6 The LC Send component. . . . . . . . . . . . . . . . . . . . . 32

3.7 Detailed view of the LC Send component. . . . . . . . . . . . 33

3.8 Activity time line of the BMAC protocol. . . . . . . . . . . . 34

3.9 Activity time line of the XMAC protocol. . . . . . . . . . . . 35


56

List of Tables

3.1 Parameter comparison between the BMAC and XMAC pro-tocols when sending. . . . . . . . . . . . . . . . . . . . . . . . 35

3.2 Parameter comparison between the BMAC and XMAC pro-tocols when receiving. . . . . . . . . . . . . . . . . . . . . . . 36


NotationsFigure 1 illustrates notations used in this thesis. In Table 1 we have sum-marized notations used in component and state diagrams. In the descriptioncolumn we have explained their meaning.

(a) A Component. (b) A Multi-component. (c) Provides interface.

(d) Provides feedback. (e) Event. (f) Timer component.

(g) Junction. (h) Fork.

Figure 1: Notations symbols.

Figure Description1a Component.1b Multi-Component.1c Interface: components can use it.1d Socket: components can listen to it.1e Even: arrow indicates event direction.1f Timer component.1g Junction: callback from several components. Not necessarily at the same

time.1h Fork: event that several components listen for. Not necessarily at the

same time.

Table 1: Description of the notations.

58

Bibliography

[1] A. Bachir, D. Barthel, M. Heusse, and A. Duda. Micro-frame preamblemac for multihop wireless sensor networks. Communications, 2006.ICC ’06. IEEE International Conference on, 7:3365–3370, June 2006.

[2] Michael Buettner, Gary V. Yee, Eric Anderson, and Richard Han. X-mac: a short preamble mac protocol for duty-cycled wireless sensornetworks. In SenSys ’06: Proceedings of the 4th international conferenceon Embedded networked sensor systems, pages 307–320, New York, NY,USA, 2006. ACM.

[3] TinyOS Community. Tinyos community forum. http://www.tinyos.net/, November 2009.

[4] P.P. Czapski. A survey: Mac protocols for applications of wirelesssensor networks. TENCON 2006. 2006 IEEE Region 10 Conference,pages 1–4, Nov. 2006.

[5] I. Demirkol, C. Ersoy, and F. Alagoz. Mac protocols for wireless sensornetworks: a survey. Communications Magazine, IEEE, 44(4):115–121,April 2006.

[6] C.C. Enz, A. El-Hoiydi, J.-D. Decotignie, and V. Peiris. Wisenet: anultralow-power wireless sensor network solution. Computer, 37(8):62–70, Aug. 2004.

[7] V. Gehrmann (FHG) G. Cugola (CEF), M. Hellenschmidt et al. Up-dated state of the art in communication protocols with associatedpartner expertise. http://www.hitech-projects.com/euprojects/wasp/, September 2008.

[8] Object Management Group. The unified modeling language. http://www.uml.org/, October 2009.

[9] Global Inventures/ZigBee. Zigbee alliance – home page. http://www.zigbee.org, November 2009.

http://www.tinyos.net/

http://www.tinyos.net/

http://www.hitech-projects.com/euprojects/wasp/

http://www.hitech-projects.com/euprojects/wasp/

http://www.uml.org/

http://www.uml.org/

http://www.zigbee.org

http://www.zigbee.org


[10] Holger Karl and Andreas Willig. Protocols and Architectures for Wire-less Sensor Networks. Wiley-Interscience, 2007.

[11] James F. Kurose and Keith W. Ross. Computer Networking: A Top-Down Approach Featuring the Internet. Addison Wesley PublishingCompany, July 2000.

[12] P. Lin, C. Qiao, and X. Wang. Medium access control with a dynamicduty cycle for sensor networks. Wireless Communications and Network-ing Conference, 2004. WCNC. 2004 IEEE, 3:1534–1539 Vol.3, March2004.

[13] Piyush Naik and Krishna M. Sivalingam. A survey of MAC protocolsfor sensor networks. Kluwer Academic Publishers, Norwell, MA, USA,2004.

[14] J. Nordlander et al. Timber - the programming language. http://www.timber-lang.org/, October 2009.

[15] J. Nordlander, M.P. Jones, M. Carlsson, R.B. Kieburtz, and A. Black.Reactive objects. Object-Oriented Real-Time Distributed Computing,2002. (ISORC 2002). Proceedings. Fifth IEEE International Sympo-sium on, pages 155–158, 2002.

[16] Joseph Polastre, Jason Hill, and David Culler. Versatile low power me-dia access for wireless sensor networks. In SenSys ’04: Proceedings ofthe 2nd international conference on Embedded networked sensor sys-tems, pages 95–107, New York, NY, USA, 2004. ACM.

[17] V. Rajendran, J.J. Garcia-Luna-Aveces, and K. Obraczka. Energy-efficient, application-aware medium access for sensor networks. MobileAdhoc and Sensor Systems Conference, 2005. IEEE International Con-ference on, pages 8 pp.–630, Nov. 2005.

[18] Venkatesh Rajendran, Katia Obraczka, and J. J. Garcia-Luna-Aceves.Energy-efficient collision-free medium access control for wireless sensornetworks. In SenSys ’03: Proceedings of the 1st international conferenceon Embedded networked sensor systems, pages 181–192, New York, NY,USA, 2003. ACM.

[19] G.A. Rollings and D.W. Corne. Intelligent operators for localisation ofdynamic smart dust networks. Hybrid Intelligent Systems, 2008. HIS’08. Eighth International Conference on, pages 477–482, Sept. 2008.

[20] Kazem Sohraby, Daniel Minoli, and Taieb Znati. Wireless Sensor Net-works: Technology, Protocols, and Applications. Wiley-Interscience,2007.

60

http://www.timber-lang.org/

http://www.timber-lang.org/


[21] Pablo Suarez, Carl-Gustav Renmarker, Adam Dunkels, and ThiemoVoigt. Increasing zigbee network lifetime with x-mac. In REALWSN’08: Proceedings of the workshop on Real-world wireless sensor net-works, pages 26–30, New York, NY, USA, 2008. ACM.

[22] B. Warneke, M. Last, B. Liebowitz, and K.S.J. Pister. Smart dust:communicating with a cubic-millimeter computer. Computer, 34(1):44–51, Jan 2001.

[23] Wikipedia. Component-based software engineering. http://en.wikipedia.org/wiki/Component-based_software_engineering,October 2009.

[24] Wei Ye, J. Heidemann, and D. Estrin. An energy-efficient mac protocolfor wireless sensor networks. INFOCOM 2002. Twenty-First AnnualJoint Conference of the IEEE Computer and Communications Soci-eties. Proceedings. IEEE, 3:1567–1576 vol.3, 2002.

[25] Wei Ye, J. Heidemann, and D. Estrin. Medium access control withcoordinated adaptive sleeping for wireless sensor networks. Networking,IEEE/ACM Transactions on, 12(3):493–506, June 2004.

[26] T. Zheng, S. Radhakrishnan, and V. Sarangan. Pmac: an adaptiveenergy-efficient mac protocol for wireless sensor networks. Parallel andDistributed Processing Symposium, 2005. Proceedings. 19th IEEE In-ternational, pages 8 pp.–, April 2005.

61

http://en.wikipedia.org/wiki/Component-based_software_engineering

http://en.wikipedia.org/wiki/Component-based_software_engineering

2009:002 civ master's thesis

Documents