Giao Thuc T-MAC Cho Mang Cam Bien Khong Day

8/7/2019 Giao Thuc T-MAC Cho Mang Cam Bien Khong Day

1/50

J.M. van Dam

An Adaptive Energy-Efficient MAC Protocolfor Wireless Sensor Networks

June, 2003


2/50


3/50

J.M. van Dam

An Adaptive Energy-Efficient MAC Protocolfor Wireless Sensor Networks

Afstudeerverslag

Auteur : J.M. van DamStudienr. : 9170094Richting : parallelle en gedistribueerde systemenDatum : 13 juni 2003

Basiseenheid Parallelle en Gedistribueerde SystemenFaculteit Electrotechniek, Wiskunde en InformaticaTechnische Universiteit Delft


4/50

ii


5/50

Afstudeergegevens

Afstudeervoordracht Parallelle en Gedistribueerde Systemen

Spreker: Tijs van DamOnderwerp: Een energie-efficient MAC protocol voor draadloze

sensornetwerken

Datum: 13 juni 2003

Tijd: 15.00

Plaats: TU Delft, Gebouw Elekrotechniek, Mekelweg 4, Zaal E

Afstudeer- Prof.dr.ir. H.J. Sips

commissie: Dr. K.G. Langendoen

Dr. S.A. van Langen

----------------------------------------------------------------

Samenvatting: Draadloze sensornetwerken zijn ad-hoc multi-hop

netwerken van sensornodes. Dit zijn zeer kleine

embedded systemen met een processor, een radio en eenof meer sensoren. Deze nodes worden gevoed door

batterijen, wat het energieverbruik zeer belangrijk

maakt. Door de minimalistische hardware is het niet

wenselijk om traditionele netwerkprotocollen te

gebruiken.

In deze opdracht is een energiezuinig MAC protocol

ontwikkeld, dat het mogelijk maakt om de radio het

grootste deel van de tijd uit te zetten. Dit protocol

is ontworpen met behulp van simulaties en later

geimplementeerd op daadwerkelijke hardware. Het

resultaat is zeer veelbelovend.

iii


6/50

iv


7/50

Preface

This report represents the end of a decade at the University of Delft. It de-scribes my graduation project on a MAC protocol for wireless sensor networks.Although I had never heard of such networks before I started, I must say that I

have learned a lot during this research, and that it has been a very interestingsubject. The field is very diverse, and much ground has not been covered yet.My work included, among other things, theoretical experiments in a discreteevent simulator, but also the calculation of a maximum bit run length in a sig-nal, based on capacitator values. All of this was new to me, and I have had afun time exploring all the technologies.

This project was part of the Consensus project, a joint project of the Univer-sity of Delft and the University of Twente. The project focuses on ubiquitouscomputing, and especially on sensor networks. The meetings with the peoplefrom Twente have added positively to the experience.

I would like to thank Niels and Koen for their continuous input. I would also liketo thank Ivaylo for helping out with the power measurements. And of courseLex Winter for the great merguez sausages.. .

Tijs van DamDen Haag, June 2003

v


8/50

vi


9/50

Contents

Afstudeergegevens iii

Preface v

Abstract ix

1 Introduction 11.1 The EYES hardware . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 the MAC layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Communication patterns . . . . . . . . . . . . . . . . . . . . . . . 41.4 Problem description and research goal . . . . . . . . . . . . . . . 5

2 Background and related work 72.1 Traditional MAC protocols . . . . . . . . . . . . . . . . . . . . . 72.2 Energy saving solutions . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 The S-MAC protocol . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 The T-MAC protocol 133.1 Main design criterium . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Basic protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.3 Clustering and synchronization . . . . . . . . . . . . . . . . . . . 153.4 Tuning and additional features . . . . . . . . . . . . . . . . . . . 153.5 Asymmetric communication . . . . . . . . . . . . . . . . . . . . . 17

4 Simulation experiments 214.1 Simulation setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5 Real-world experiments 295.1 Operating environment . . . . . . . . . . . . . . . . . . . . . . . . 295.2 Implementation issues . . . . . . . . . . . . . . . . . . . . . . . . 305.3 Power usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6 Conclusions and future work 35

vii


10/50

viii


11/50

Abstract

Wireless sensor networks are collections of sensors that are equipped with aradio and form a wireless network together. The main advantages of wirelesssensor networks are fast and easy deployment, and low maintenance cost. En-

ergy is a scarce resource in such networks, which has a great impact on thedesign of hardware and software. The hardware is cheap and limited. Softwareis specialized; network protocols must be designed for sensor communicationpatterns and focus on low energy consumption. The easiest way to reduce en-ergy consumption is to turn off the radio when it is not needed.

We present the T-MAC protocol, a medium access control protocol designedspecially for wireless sensor networks. T-MAC lets wireless sensor nodes turnon their radio at synchronized times, and turn them off after a certain time-outwhen no communication occurs during some time. Messages are transmitted inbursts. This scheme allows dynamic adaption of the radio-on time to changingmessage rates. The T-MAC protocol saves more energy than its predecessor

S-MAC in a network where message rates vary. The S-MAC protocol lets nodesturn the radio on for a fixed time. S-MAC requires tuning to the message rate,whereas T-MAC does not.

The T-MAC protocol has a problem with asymmetric communication patterns,where nodes may go to sleep while their neighbors still have messages for them.This early sleeping problem reduces the maximum throughput dramatically.Two proposed solutions for this problem together double the throughput, butit is still less than 70% of the maximum throughput of other protocols. This isa trade-off to the adaptiveness of the protocol. However, we do not expect suchhigh message rates in wireless sensor networks.

Simulation experiments have shown that the T-MAC protocol reduces the en-ergy used by the radio with as much as 80%, in a typical scenario and comparedto classical protocols like CSMA. The S-MAC protocol saves only 30% in thisscenario, after optimal tuning.

Implementation of the T-MAC protocol on real wireless sensor hardware hasshown that, in an idle situation, the radio can be turned off for as much as 97.5%of the time, reducing the total energy used with more than 96%. In a situationwith high message rates, the T-MAC protocol does not increase the latency,since nodes do not sleep in that case. The T-MAC protocol implementation issimple and uses only 42 bytes of state.

ix


12/50

x


13/50

Chapter 1

Introduction

Sensor networks have existed for a long time. They typically consist of sensors(e.g. infrared, temperature, sound, motion detectors) wired to a control sta-tion. The control station receives the sensor data and performs some kind ofprocessing: recording the data, comparing data from different sensors, ringingan alarm, etc.

Wireless sensor networks [2] communicate via a radio interface instead ofbeing wired to a control station (Figure 1.1). Sensors themselves are normallynot equipped with a radio interface. Therefore, a simple signal processor anda radio are packaged together with one or more sensors into what is called awireless sensor node. The sensor is used to perform measurements and theradio to transmit these measurements to interested parties. The processor is

needed to drive the sensors and the radiowe would not want a continuousradio signal; to save energy and because of radio transmission regulations, radiotransmission should only take place periodically, or when measurements exceedsome threshold.

The use of a wireless network has several advantages when compared to atraditional, wired network:

since no wires have to be placed, deployment can be extremely fast; urbanwarfare situations and temporary, short-term security are examples;

deploying and maintaining a network of wires is costly; at some point theadded cost of a processor and a radio will outweigh maintenance cost;

Wireless sensor

Wireless control station

Figure 1.1: A quickly-deployable wireless infrared intrusion-detection network.

1


14/50

in some situations it may not be feasible to wire the network; think for

example of forest fire detection or other environmental measurementswireless sensor nodes could even be dropped from an airplane;

Wireless sensor nodes can be powered by batteries, or some form of ambientenergy (e.g. temperature differences). Since batteries have only a limited ca-pacity, and ambient energy is limited itself, energy consumption is central inthe design of wireless sensor hardware and software. Relevant issues are:

Different trade-offs In most wireless networks, hardware and software are de-signed to maximize network throughput and to minimize latency. In wire-less sensor networks, these are less important. The trade-off of throughputand latency versus energy usage is different, resulting in different, special-ized network protocols.

Multi-hop To minimize radio energy usage, the radio sending capacity is lim-ited. To bridge large distances, messages must travel multiple hops toreach their destination. Nodes must be able to relay messages for othernodes.

Ad-hoc We expect wireless sensor networks to live on their own: each nodeis equal (although some may be more equal than others) and there is nocentral, high power base station to regulate traffic. This is called ad-hocnetworking.

Send only important messages Since sending messages costs energy, thenumber of messages sent must be kept to a minimum. This means thatonly important messages are sent. For example, instead of sending a sen-

sor measurement every second, we can choose to send a message only whenthe measurement exceeds a threshold.

Local processing The advantage of having a processor with each sensor isthat we can use it to perform some extra processing. For example, it ispossible to calculate the daily average of some sensor data, and to sendonly the average. If the average is all we need, we still get all relevantinformation, while reducing the amount of messages.

In-network processing It is likely that real-world events will be noticed byseveral sensor nodes. Instead of each node transmitting a message toa control stationwhich may be tens of hops away, nodes can conferlocally and agree that only one of them sends a messagethe processing

in this case is some distributed algorithm. Another form of in-networkprocessing is data aggregation, whereby messages from different nodes arecombined by relaying nodes. For example, the relaying node could relayonly the average of the measurements of two different nodes.

1.1 The EYES hardware

To compete with wired sensors, wireless sensor nodes should be cheap. There-fore, they generally have very limited hardware. To make the reader comfortablewith the capacities of wireless sensor hardware, we will elaborate on a specificwireless sensor node design: the EYES nodes (Figure 1.2). These nodes have

2


15/50

RS232

Antenna CPU

Radio

Sensor I/O

Figure 1.2: The EYES wireless sensor node. No sensors have been added yet.

been developed for the international EYES project [14], and our research isbased on these nodes. The main components of the EYES nodes are:

CPU The processor is a 16-bit Texas Instruments MSP430F149 [10], whichruns at about 5 MHz. It has only 2 KB of RAM and 60 KB of programmemory (ROM). It also has two internal UARTs, which can buffer a byteof data and allow the processor to work on bytes instead of bitsallowingthe processor to do other work, or sleep, between bytes. The UARTs areused for both radio and serial communication.

Radio The node is equipped with a single-frequency radio (RFM TR1001,868.35MHz [6]) that has been configured for a data speed of 115200 bitsper second. It requires a DC-balanced signal and is connected to one ofthe UARTs of the processor. The transmit signal goes through a digitalpotentiometer to adjust the transmit power. The radio uses approximately10 mA while transmitting, 4 mA while listening/receiving and 20 A insleep mode. Note that listening costs 200 times as much energy as sleeping.

EEPROM The node has a 256 KB EEPROM module, which can be seriallywritten and read from the processor. It is too slow and impractical to use,for example, as extra RAM memory, but can be used to store long-termdata like program modules.

Serial port The other UART of the processor is, via a voltage converter, con-nected to a serial RS232 interface. This is useful for printing debug mes-sages and interfacing with programs on a PC.

The component that consumes the most energy is the radio. An importantaspect of the radio is that having it in listen/receive mode costs almost half asmuch energy as when it is transmitting. This is typical for wireless hardware [9].

The processor specifications (2 KB RAM, 60 KB program) may seem veryminimal, but, in fact, the EYES hardware is quite generous compared to someother sensor nodes that have been developed [15].

1.2 the MAC layer

Since trade-offs in wireless sensor networks are different than in ordinary wire-less networks, and since hardware is much more limited, specialized network

3


16/50

Figure 1.3: Communication patterns: (event-based) local unicast and nodes-to-sink reporting.

protocols need to be designed.

Network protocols can be classified into layers. One of these is the data link

layer (OSI layer 2). This layer provides communication at the link level. Inwireless communication, a link consists of two nodes directly communicatingvia the radio. Part of the responsibility of the data link layer is to determinewhich node may access the medium at what time. We commonly refer to thistask as medium access control (MAC). It is especially important in a sharedmediumlike the air, since multiple nodes transmitting at the same time willinterfere each others communication.

Since a network contains multiple independent nodes, an agreement is neededfor medium access control. This agreement should be shared by all nodes in thenetwork. It takes the form of a network protocol and is called a MAC protocol.The MAC protocol may consist of complex negotiations and provisions for lostmessages.

In a wireless environment, the MAC protocol determines the state of theradio on a nodesending, receiving, or sleeping. Since the radio, while listeningor transmitting, uses relatively much energy, the MAC is a good place to saveenergy. A MAC protocol for wireless sensor networks should focus on energyusage, and ensure that radios are in sleep mode as much as possible.

1.3 Communication patterns

It is important to design and test the behavior of MAC protocols based on thekind of traffic they have to handle. We have identified two main communicationpatterns in sensor applications (Figure 1.3):

Local unicast/broadcast When a real-world event in the network occurs, weexpect nodes to perform some in-network processing. This will generallyinvolve local messages being exchanged between neighbors.

Nodes to sink reporting After processing a local event, or just periodically,nodes may need to report something. We expect messages to be directedto one or a few sink nodes, which are hooked up to a fixed network ora computerlike a control board in a wired sensor network. Messagesfrom different nodes may, or may not, be aggregated along the way. Inthis communication pattern, we see a more or less unidirectional flow ofmessages through the network.

4


17/50

We explicitly exclude routed, multi-hop communication between random nodes

in the network, although this pattern is frequently used to study MAC protocols.After identifying several realistic wireless sensor applications, we determinedthat this communication pattern does not occur.

We also assume that nodes are not moving. This is true for all applicationswe have identified. Future applications, or expansion of wireless sensor technol-ogy into other fields, may yield moving nodes. However, we do not take thisinto account.

The two basic communication patterns imply that the message rate in the net-work may vary, both in time and location: events trigger periods of increasedactivity, and, around sink nodes, the message rate will be higher than at the(other) edge of the network, even when aggregation is used.

1.4 Problem description and research goal

Most energy in traditional MAC protocols is wasted by idle listening: since anode does not know when it will be the receiver of a message from one of itsneighbors, it must keep its radio in receive mode whenever it is not transmitting.Consider, for example, a sensor application that requires nodes to exchangemessages with their neighbors at an average rate of one per second. Messagesare fairly short: they take less than 5 milliseconds to transmit. This results ineach node spending an average of 5 ms per second on transmitting, 5 ms onreceiving a message from another node, and 990 ms on listening while nothinghappens. The radio is then idle listening, doing nothing useful, for 99% of thetime.

The goal of this research is to design a MAC protocol for wireless sensor net-works that minimizes energy usage, while considering wireless sensor commu-nication patterns and hardware limitations. We will mainly focus on reducingidle listening, since we expect to save most energy in this area.

The work-flow of the project has been as follows: first, we have studied existingMAC protocols and energy-saving solutions. We have implemented some pro-tocols in a simulation program to compare them and study them better. Thenwe have designed a new protocol, T-MAC, partly based on an existing MACprotocol for wireless sensor networks. We have implemented this protocol inthe simulator as well. After identifying and solving some problems, we have

implemented and tested most of the protocol on the actual EYES hardware.

5


18/50

6


19/50

Chapter 2

Background and related

work

In this chapter we will present some of the theoretical background of this re-search. We will start with a classification of traditional MAC protocols, theirproblems and the way these have been solved. Then we will present MAC-relatedenergy saving solutions that have been proposed until today. Finally, we willdescribe in detail the S-MAC protocol, which has inspired our own design.

2.1 Traditional MAC protocols

The family of MAC protocols can broadly be divided into two categories: proto-cols that do not, and protocols that do allow simultaneous access to the medium.Protocols in the first category define some access scheme. An example is to leteach node at its turn transmit a message. When the message has ended, thenext node may send. If a node has nothing to send, a special message is sent.This is known as token-passing. We know of no direct application of token-passing in wireless networks. Another way is to divide the time into framesof a certain length, and to divide each frame into slots. Each slot is ownedby a certain node. A node can only send in its own slot. This method isknown as Time Division Multiple Access (TDMA) and is widely used in wire-less communicationespecially when there is a central base station that can bein charge of slot allocation.

The second category consists of MAC protocols that allow more nodes toaccess the medium at the same time. Collisions may then occur, but are dealtwith. A classic example of such a protocol is Carrier Sense Multiple Access(CSMA). In this protocol, a node that needs to transmit a message will scan(sense) the medium for ongoing communication. If the node determines thatthe medium is busy, it will back off and retry later. When the medium is clear,the node waits for a random period, the contention period, before sending. Thecontention period decreases the probability that two nodes start sending atthe same moment and is therefore very important. Every protocol that allowsmultiple nodes to send at the same time features such a contention period.These protocols are therefore also known as contention-based protocols.

7


20/50

A B C

Figure 2.1: The hidden terminal problem. Nodes A and C are out of each othersreach.

A B C D

Figure 2.2: The exposed terminal problem. Node C will defer transmission to

D, although this is not needed.

In general, contention-based protocols are simpler than TDMA-based proto-cols. In a multi-hop, ad-hoc network, like wireless sensor networks, slot alloca-tion becomes a two-hop graph coloring problem (a node can re-use a slot whennone of its two-hop neighbors uses it). This problem is complex and requiresefficient coordinationespecially in denser networks. Furthermore, as TDMAdivides time into small slots, exact timing is important. Time synchronizationbecomes a critical aspect.

2.1.1 The hidden terminal problem: MACA

Traditional CSMA, when applied to a multi-hop wireless network, suffers froma classic problem: the hidden terminal problem. It stems from the fact that,in wireless communication, collision happens at the receiver [4]. Two nodesthat are out of each others reach could be transmitting to a third node in themiddle (Figure 2.1). The middle node will receive neither message, since thetransmissions interfere with each other. Carrier sensing does not help in thiscase, since that happens at the sender: the two sending nodes both perceivedthe air as clear before they started sending.

Another problem is the exposed terminal problem. In Figure 2.2, node B issending to node A. Node C will defer sending to node D, because it waits for Bstransmission to end. However, since D is out of the reach of Bs transmission,there would be no interference at the receiver and therefore no problem. Some

of the possible throughput is lost by Cs waiting.Both these problems are addressed by the Multiple Access with Collision

Avoidance (MACA) scheme [4]. In this scheme, the node that needs to transmita message sends a small Ready-To-Send (RTS) message to the receiver. Thereceiver immediately responds with a Clear-To-Send (CTS) message. Afterreceiving the CTS, the sender will transmit the data message. Both the RTSand the CTS messages carry the length of the data message.

When a node overhears an RTS message destined for another node, it isprohibited from sending during the time needed for the other node to send aCTS message. A node that overhears a CTS message is prohibited from sendingduring the time needed to transmit the data message. No carrier sensing is used.

8


21/50

This scheme solves the hidden terminal problem: a node that could otherwise

interfere with a transmission (like node C in Figure 2.1) will at least hear theCTS from the receiver of the message and remain silent. The RTS and CTSmessages are very small and therefore unlikely to collide. The exposed terminalproblem is also solved: a node that receives an RTS message, but not thecorresponding CTS message, is allowed to transmit.

For historys sake we should acknowledge that the RTS/CTS scheme was first usedby the Apple Localtalk network. The reason was that the communication chip in theApple Macintosh could only buffer three bytes. The RTS, which could fit into thebuffer, gave the receiver a chance to allocate buffer space and get the CPU readyto receive the data. The creators of the protocol recognized the collision avoidanceadvantage (although this network was mainly used in a single cell without hiddenterminals) and named it CSMA/CA (CSMA with collision avoidance). Phil Karn,

who described MACA, recognized that this scheme was the solution for the hiddenand exposed terminal problems and proposed to take away the carrier sensing (CS,leaving MA/CA). [1]

2.1.2 MACAW and IEEE 802.11

The MACAW protocol (MACA Wireless?) made some significant improvementsto the MACA protocol [1]. Most importantly, an acknowledgement was intro-duced. After sending the data packet, the receiver responds with a small ACKmessage. If the sending node does not receive the ACK, it can retry the oper-ation. This way, reliability is built into the protocol, which is advantageous inunreliable wireless communication.

The well known protocol IEEE 802.11 was being developed when MACAW

was proposed [5]. It uses a similar RTS/CTS/DATA/ACK mechanism. Itspurpose was mainly to wirelessly connect portable computers and PDAs. Fur-thermore, although multi-hop networks and interference have been a designissue, the IEEE 802.11 protocol was designed mainly for single cell networks.

Since the exposed terminal problem is not a big problem, and since theRTS/CTS mechanism does not always perfectly avoid collisions, IEEE 802.11re-introduces medium sensing. The advantage of medium sensing was consideredmore important than the exposed terminal problem.1

2.2 Energy saving solutions

Several solutions exist that address the problem of energy waste due to idlelistening. Each solution allows the node to turn off its radio at times. We canbroadly specify three classes of solutions: TDMA-based, special hardware, andcontention-based with a duty cycle.

2.2.1 TDMA-based energy saving

TDMA-based protocols have a natural duty cycle built-in. It is possible thatnodes only have their radio on during their slot. This way, during periods of

1The exposed terminal problem was described by Phil Karn in terms of relay stationson top of hills, which were obstructed from communicating with local stations by anotherfar-away relay station [4].

9


22/50

low traffic, the radio only has to be on for 1/nslots time. More energy can be

saved by dividing each slot into functional parts. For example, the beginningof a slot can be an announcement phase. During this phase, other nodes mayannounce themselves. If no announcements take place, and the owner of a slothas no message to send, it can turn off its radio immediately [3]. However, aswe have already determined, this requires much complexity and critical timingin the nodes. We think that TDMA-based protocols require too much for thecurrent cheap hardware.

2.2.2 Special hardware

A promising energy-saving solution is to use special signalling hardware to an-nounce relevant communication. A node can turn on its radio after having beensignalled. The most straight-forward way of signalling is to use an extra radio

the so-called wake-up radio, which operates at a different frequency than theradio used for communication [8]. It may seem strange to use a radio to allowshutting down another radio, but we need to keep in mind that the wake-upradio is only used for signalling. No data processing is required, which meansthat the receiver can be very simple and requires much less energy than thehardware used for data communication.

Although the wake-up radio is a promising solution, most wireless sensornodes currently used in research are not equipped with extra radiosand theEYES hardware is no exception.

2.2.3 Duty cycle in contention-based protocols

To be able to turn off the radio in single-frequency, contention-based protocols,we must introduce some kind of active/sleep duty cycle. Using only in-bandsignalling, nodes must agree to periodically sleep, and buffer messages until thenext active period.

The IEEE 802.11 protocolin ad-hoc modehas power saving capabilities,which use such a duty cycle. At synchronized times, nodes can go to sleep.At the beginning of the active period of the duty cycle, messages called trafficindication maps (TIMs) are exchanged, which indicate to nodes that they muststay awake to receive messages. Unfortunately, this protocol was designed withthe presumption that all nodes are located in a single network cell, while wirelesssensor networks will generally be multi-hop. Adaptions for multi-hop networkshave been proposed, but seem to require more complexity and dynamic state

than would generally be available in wireless sensor networks [11].A simpler protocol is the S-MAC protocol [13], which was specifically de-signed for wireless sensor networks. This is the protocol we used as a base forour design and for comparing results.

2.3 The S-MAC protocol

As explained in Section 2.2.3, the S-MAC protocol is a single-frequency con-tention-based protocol for sensor networks. The basic idea is that time is dividedintofairly largeframes. Every frame has two parts: an active part and asleeping part. During the sleeping part, a node turns off its radio to preserve

10


23/50

sleep sleep sleep

Figure 2.3: The S-MAC duty cycle; the arrows indicate transmitted messages.On the left CSMA, on the right S-MAC. Note that messages come closer to-gether.

energy. During the active part, it can communicate with its neighbors and sendany messages queued during the sleeping part, as shown in Figure 2.3. Sinceall messages are packed into the active part, instead of being spread out overthe whole frame, the time between messages, and therefore the energy wastedon idle listening, is reduced.

S-MAC needs some time synchronization, but that is not as critical as inTDMA-based protocols: the time scale is much larger. Typically, there may bean active part of 200 ms in a frame of one second. A clock drift of 500 s willnot be a problem.

The S-MAC protocol basically trades used energy for throughput and la-tency. Throughput is reduced because only the active part of the frame is usedfor communication: the remaining throughput scales linearly with the frac-tion of the active part within the frame. Latency increases because a message-generating event may occur during sleep time. In that case, the message will bequeued until the start of the next active part.

In the protocol, medium sensing and collision avoidance (RTS/CTS) is used,together with acknowledgement, like in the IEEE 802.11 protocol (Section 2.1.2).

To save even more energy, the radio is turned off after overhearing an RTS or aCTS destined for another node: the overhearing node is prohibited from usingthe medium during a certain time, so it may turn off the radio as well. Thisfeature is called overhearing avoidance.

S-MAC has two important parameters: the total frame time, which is limitedby latency requirements and buffer space, and the active time. The active timedepends mainly on the message rate: it can be so small that nodes are able totransfer all their messages within the active time.

11


24/50

12


25/50

Chapter 3

The T-MAC protocol

In this chapter, we will describe the design of the T-MAC protocol. We willfirst present the main design criterium, and explain why the S-MAC protocoldoes not meet this criterium in an optimal way. After that, we will describethe basic scheme of the T-MAC protocol, followed by the virtual clusteringtechnique used for synchronization. Then, we will add some protocol-specificsettings and features. Finally, we will present a major problem we encountered,and the ways we solved this problem.

3.1 Main design criterium

Energy usage is the main design criterium for our MAC protocol design. We

have already identified the problem of idle listening. Other forms of energywaste are:

collisions if two nodes transmit at the same time and interfere with each oth-ers transmission, packets are corrupted. Hence, the energy used duringtransmission and reception is wasted;

protocol overhead most protocols require control packets to be exchanged;as these contain no application data, we consider any energy used fortransmitting and receiving these packets as overhead;

overhearing since the air is a shared medium, a node may receive packets thatare not destined for it; it could then as well have turned off its radio.

These other sources of energy usage are relatively insignificant when comparedto the idle listening energy waste, especially when messages are infrequent.Consider our example where 99% of the time is spent on idle listening. If, then,the actual transmission and receiving time increases by a factor twodue tocollisions and overhead, idle listening time decreases only from 99% to 98%.

Although reducing the idle listening time, a solution with a fixed duty cycle,like the S-MAC protocol, is not optimal. Remember that the active time withinthe frame is dependent on the required throughput (Section 2.3).

The problem is that, while latency requirements and buffer space are gener-ally fixed, the message rate will usually vary (Section 1.3). If important messages

13


26/50

TA TA TA TA TA TA

Figure 3.1: The basic T-MAC protocol scheme, with adaptive active times.

are not to be missedand unimportant messages should not have been sent inany case, the nodes must be deployed with an active time that can handle thehighest expected load. Whenever the load is lower than that, the active time isnot optimally used and energy will be wasted on idle listening.

The novel idea of the T-MAC protocol is to reduce idle listening by transmit-

ting all messages in bursts of variable length, and sleeping between bursts. Tomaintain an optimal active time under variable load, we dynamically determineits length. We end the active time in an intuitive way: we simply time out onhearing nothing.

3.2 Basic protocol

Figure 3.1 shows the basic scheme of the T-MAC protocol. Every node periodi-cally wakes up to communicate with its neighbors, and then goes to sleep againuntil the next frame. Meanwhile, new messages are queued. Nodes communicatewith each other using a Request-To-Send (RTS), Clear-To-Send (CTS), Data,

Acknowledgement (ACK) scheme, which provides both collision avoidance andreliable transmission (Section 2.1).

A node will keep listening and potentially transmitting, as long as it is inan active period. An active period ends when no activation event has occurredfor a time TA. An activation event is:

the firing of a periodic frame timer;

the reception of any data on the radio;

the sensing of communication1 on the radio, e.g. during a collision;

the end-of-transmission of a nodes own data packet or acknowledgement;

the knowledge, acquired through overhearing prior RTS and CTS packets,that a data exchange of a neighbor has ended.

A node will sleep if it is idle and not in an active period. Note that TA is anupper bound on the idle listening time per frame at the end of the active time.

The described timeout scheme moves all communication to a burst at thebeginning of the frame. Since messages between active times must be buffered,the buffer capacity determines an upper bound on the maximum frame time.

1Through a Received Signal Strength Indication (RSSI) signal from the radio.

14


27/50

A

B

C

D

Figure 3.2: Multiple schedules; nodes B and C, which form the border betweentwo virtual clusters, have multiple schedules.

3.3 Clustering and synchronization

Frame synchronization is inspired by virtual clustering, as described by the

authors of the S-MAC protocol [13]. When a node comes to life, it starts bywaiting and listening. If it hears nothing for a certain amount of time, it choosesa frame schedule and transmits a SYNC packet, which contains the time untilthe next frame starts. If the node, during startup, hears a SYNC packet fromanother node, it follows the schedule in that SYNC packet and transmits itsown SYNC accordingly.

Nodes retransmit their SYNC once in a while. Nodes must also listen fora complete frame sporadically, so they can detect the existence of differentschedules. This allows new and mobile nodes to adapt to an existing group.

If a node has a schedule and hears a SYNC with a different schedule fromanother node, it must adopt both schedules. It must also transmit a SYNCwith its own schedule to the other node, to let the other node know about the

presence of another schedule. Adopting both schedules means that the nodewill have an activation event at the start of both frames. This is depicted inFigure 3.2, where nodes B and C have double schedules, allowing them to actas border nodes between the virtual clusters A-B and C-D.

Nodes must start a data transmission only at the start of their own activetime. At that time, both neighbors with the same schedule, and neighborsthat have adopted the schedule as extra, are awake. If a node would starttransmission at the start of a neighbors frame, it might be transmitting toanother, sleeping neighbor. Note that broadcasts only need to be transmittedonce.

The described synchronization scheme, which is called virtual clustering [13],urges nodes to form clusters with the same schedule, without enforcing this

schedule to all nodes in the network. It allows efficient broadcast, and obviatesthe need to maintain information on individual neighbors.

The virtual clustering technique is easy to implement. Keeping multipleschedules with a fixed-length active time is more complex, since active timesmay overlap.

3.4 Tuning and additional features

We will now discuss some (additional) features of the T-MAC protocol, whichprovide better tuning.

15


28/50

RTS CTS DATA ACKA

B

C

TA

contend

contend

Figure 3.3: A basic data exchange. Node C overhears the CTS from node B andwill not disturb the communication between A and B. TA must be long enoughfor C to hear the start of the CTS.

3.4.1 Fixed contention interval

In contention-based protocols, like IEEE 802.11, nodes wait for a random timewithin a contention interval after detecting a collision. Only when the air isclear during that time do they restart transmission. Usually, a back-off schemeis used: the contention interval increases when traffic is higher. The back-off scheme reduces the probability of collisions when the load is high, whileminimizing latency when the load is low.

In the T-MAC protocol, every node transmits its queued messages in aburst at the start of the frame. During this burst, the medium is saturated:messages are transmitted at maximum rate. A node may expect to be in afierce fight for winning the medium every time it sends an RTS. An increasingcontention interval is not useful, since the load is mostly high and does notchange. Therefore, RTS transmission in T-MAC starts by waiting and listening

for a random time within a fixed contention interval. This interval is tuned formaximum load. The contention time is always used, even if no collision hasoccurred yet.

3.4.2 RTS retries

When a node sends an RTS, but does not receive a CTS back, one of threethings has happened:

1. the receiving node has not heard the RTS due to collision; or

2. the receiving node is prohibited from replying due to an overheard RTS

or CTS; or

3. the receiving node is asleep.

When the sending node receives no answer within the interval TA, it might goto sleep. However, that would be wrong in cases 1 and 2: we would then have asituation where the sending node goes to sleep, while the receiving node is stillawake. Since this situation might occur even at the first message of the frame,the throughput would (and did, in our preliminary experiments) dramaticallydecrease.

Therefore, a node should retry by re-sending the RTS if it receives no answer.If there is still no reply after two retries, it should give up and go to sleep.

16


29/50

RTS CTS DATA ACK

D

C

B

TA

contendA

contend

sleepactive

RTS?

Figure 3.4: The early sleeping problem. Node D goes to sleep before C can sendan RTS to it.

3.4.3 Determining TAA node should not go to sleep while its neighbors are still communicating, sinceit may be the receiver of a subsequent message. Receiving the start of the RTSor CTS packet from a neighboring node is enough to trigger a renewed intervalTA.

Since a node may not hear, because it is not in range, the RTS that startsa communication with its neighbor, the interval TA must be long enough toreceive at least the start of the CTS packet (Figure 3.3). This observation givesus a lower limit on the length of the interval TA:

TA > C + R + T

where C is the length of the RTS contention interval, R is the length of an RTSpacket, and T is the turn-around time (the short time between the end of theRTS packet and the beginning of the CTS packet). In our experiments, we usedTA = 1.5 (C+ R + T), which proved to be satisfactory. A larger TA increasesthe energy used.

3.4.4 Overhearing avoidance

The S-MAC protocol introduced the idea of sleeping after overhearing an RTSor CTS destined for another node. Since a node is prohibited from sendingduring that time, it can not take part in any communication and may as wellturn off its radio to save energy.

In general, overhearing avoidance is a good idea, and it is an option in the

T-MAC protocol. However, we have observed in our experiments that, as aside effect, collision overhead becomes higher: a node may miss other RTS andCTS packets while sleeping and disturb some communication when it wakesup. Consequently, the maximum throughput decreases; for short packets by asmuch as 25%. So although overhearing avoidance saves energy, it must not beused when maximum throughput is (at times) required.

3.5 Asymmetric communication

Preliminary experiments revealed a problem with the T-MAC protocol whentraffic through the network is mostly unidirectional, like in a nodes-to-sink com-

17


30/50

RTS CTS DATA ACK

D

C

B

TA

contend

A

contend

active

RTS

DS

FRTS

active

Figure 3.5: Future-request-to-send packet exchange.

munication pattern. This problem is simplified in Figure 3.4. Each of the nodesA though D in the picture forms a cell with its neighbors. Messages flow fromtop to bottom, so node A sends only to B, B only to C, and C only to D. Nowconsider node C. Every time it wants to send a message to D, it must contendfor the medium and may loose to either node B (by receiving an RTS packet)or to node A (indirectly, by overhearing a CTS packet from node B).

If node C looses contention because of an RTS packet from node B, it willreply with a CTS packet, which can also be heard by node D. In that case, nodeD will be awake when the communication between C and B ends. However, ifnode C looses contention because it overhears a CTS packet from B to A (seeFigure 3.4), C must remain silent. Since D does not know of the communicationbetween A and B, its active time will end, and node D will go to sleep. Only atthe start of the next frame will node C have a new chance to send to node D.

Thus for every packet that node C wants to send to node D, it may eithersucceed or fail (by loosing to node A). Both of these events have equal prob-ability. Failure implies that the frame ends and C can send no more packets.We can therefore calculate that, in this simplified setup, node C has a 50%probability of sending a single packet to node D, a 25% probability of sendingtwo packets (it must succeed twice), etcetera, in each frame.

We call the observed effect the early sleeping problem (since a node goes tosleep when a neighbor still has messages for it). In the nodes-to-sink communi-cation pattern, the early sleeping problem reduced the total possible throughputof T-MAC to less than half of the maximum throughput of traditional protocolsor S-MAC. In later experiments, we have also encountered this problem at theborder of a highly active part of the network. We believe that the problem may

occur in any asymmetric communication pattern. We devised two solutions.

Future request-to-send The first solution is a scheme that we call futurerequest-to-send. The idea is to let another node know that we still have amessage for it, but are ourselves prohibited from using the medium.

It works as follows: if a node overhears a CTS packet destined for anothernode, it may immediately send a future-request-to-send (FRTS) packet, likenode C in Figure 3.5. The FRTS packet contains the length of the blockingdata communication (this information was in the CTS packet). A node mustnot send an FRTS packet if it senses communication right after the CTS, or ifit is prohibited from sending due to a prior RTS or CTS.

18


31/50

RTS

CTS DATA ACKD

C

B

TA

contend

A

contend

contend

RTS

Figure 3.6: Taking priority upon receiving RTS.

A node that receives an FRTS packet knows it will be the future target ofan RTS packet and must be awake by that time. The node can determine thisfrom the timing information in the FRTS packet.

As the FRTS packet would otherwise disturb the data packet that follows theCTS, the data packet must be postponed for the duration of the FRTS packet.To prevent any other node from taking the channel during this time, the nodethat sent the initial RTS (node A in Figure 3.5) transmits a small Data-Send(DS) packet. After the DS packet, it must immediately send the normal datapacket.

Since the FRTS packet has the same size as a DS packet, it will collide withthe DS packet, but not with the following data packet. The DS packet is lost,but that is no problem: it contains no useful information.

For the FRTS solution to work, TA must be increased with the length of a

control packet (CTS), as follows from Figure 3.5.Implementing the FRTS feature increased the maximum throughput in uni-

directional communication patterns by 75%. However, due to the somewhathigher overhead of DS and FRTS packets, energy usage also increased slightly.One may want to use FRTS packets only if a reasonably high load in a moreor less unidirectional communication pattern is expected. Note, however, thatwhen the load is low, the number of exchanged packets, and therefore the in-creased overhead, is also low.

Taking priority on full buffers The second solution is a scheme that we call full-buffer priority. When a nodes transmit/routing buffers are almost full, itmay prefer sending to receiving. This means that when a node receives an RTSpacket destined for it, it immediately sends its own RTS packet to another node,instead of replying with a CTS like normal. This is depicted in Figure 3.6. It hastwo effects. First, the node has an even higher chance of transmitting its ownmessage, since it effectively wins the medium upon hearing a competing RTS;in Figure 3.6, node C may transmit to node D after losing contention to node B.Thus the probability that the early sleeping problem occurs is lower. Secondly,the full-buffer priority scheme introduces a limited form of flow control into thenetwork, which is advantageous in a nodes-to-sink communication pattern; inFigure 3.6, node B is prevented from sending until node C has enough bufferspace.

We must, however, be careful with the full-buffer priority scheme, since it is

19


32/50

dangerous in a high-load situation where communication is not unidirectional.

When all nodes in an omnidirectional communication pattern start taking pri-ority, chances of collisions increase rapidly. Therefore, T-MAC uses a threshold:a node may only use this scheme when it has lost contention at least twice. Thisthreshold guarded, in our experiments, the performance in an omnidirectionalcommunication pattern, while still increasing the maximum throughput in aunidirectional pattern.

20


33/50

Chapter 4

Simulation experiments

In this chapter, we will describe the protocol simulation. We will start byelaborating on our simulation setup and the model used. Then we will presentthe final results of the simulations.

4.1 Simulation setup

Our protocol design and evaluation are based on simulation. In the OMNeT++discrete event simulation package [12], we have built a realistic model of theEYES wireless sensor nodes. The model has the same limits on clock resolutionand precision, radio turn-around and wake-up times, and transmission bit ratesas the EYES nodes do. Energy usage in the model is based on the amountof energy the real nodes use: 20 A while sleeping, 4 mA while receiving and10 mA while transmitting a DC-balanced signal [6, 7, 10].

Using these modeled nodes, we have built a network of 100 nodes in a 10by 10 grid. We have chosen a radio range so that non-edge nodes all have 8neighbors (Figure 4.1). We admit that this perfect world is not a realistic setupfor most sensor networks, but it is easy implementable and a good start. Furtherresearch with a more complex network will be valuable.

4.1.1 Scenarios

Each simulation run follows some scenario. A scenario is defined as a superpo-sition of multiple pattern instances. A pattern instance is the implementation of

a communication pattern (Section 1.3) with parameters like message frequency,

Figure 4.1: Part of the simulation network. Non-edge nodes have 8 neighbors.

21


34/50

message length, etc. A pattern is basically a traffic generator, which models

some real-life message source. For example, if we want to model a networkwhere all nodes periodically report to a single sink node, we could add a nodes-to-sink pattern to our scenario, with realistic settings for message length andfrequency.

Furthermore, we define active areas. An active area models a real-life eventin the network. Active areas appear with some configurable frequency and havesome configurable lifetime and size. If we would want to model an fire detectionsystem, where the start of a fire can be detected in a range of 4 meters, wecould set active areas to appear with a very low frequency, a long lifetime, anda radius of 4.

Nodes are active when they are within one or more active areas, and idlewhen they are not. This is used by the pattern instances. Pattern instancesare either active or always-on. Active pattern instances only generate messagesin active nodes. Always-on pattern instances always generate messages, inde-pendent of the active areas. We use active patterns to model event-triggeredcommunication (detection) and always-on patterns to model event-independentcommunication (periodic reporting).

Pattern instances are independent of each other, and generate messages in-dependently. Multiple pattern instances may use the same communication pat-tern. For example, we could in a scenario have a to-sink always-on patternthat generates one message every 10 seconds, and a to-sink active pattern thatgenerates one message per second when the node is in an active area.

4.1.2 OMNeT++ model

Figure 4.2 shows the complete OMNeT++ simulation model. The model con-sists of independently programmed modules. The modules are:

Radio The radio module receives and transmits data frames. It has a state(transmit/receive/sleep) and keeps track of interference with other radios.Disturbed data frames are discarded. Energy statistics are kept in thismodule.

Mac This module is the MAC protocol. The actual implementation can bedefined in a configuration file, allowing a different MAC protocol for eachsimulation run. The MAC module exchanges data packets with the AppS-elector module, and data frames (e.g. RTS/CTS) with the radio module.

Patterns One or more pattern modules exist in each node. These are thetraffic-generating pattern instances described in Section 4.1.1. The patternmodules are the same in each node, based on the simulated scenario.

AppSelector The AppSelector module sits between the MAC and the patternmodules. It queues packets for transmission (the MAC handles only onemessage at a time) and delivers received messages to the correct patternmodule. This makes it possible for patterns to act on incoming messagesfor example, to perform multi-hop message relaying. The AppSelectormakes sure that a message from some pattern module ends up in thecorresponding pattern module in the receiving node.

22


35/50

P1 P2 P3

AppSelector

MAC

Radio

PropagationModel

P1 P2 P3

AppSelector

MAC

RadioNode 3

Node 4

Node n

AreaManager

ScenarioManager

Node 1 Node 2

Figure 4.2: The simulation model in OMNeT++. Each block is an independentmodule. The communication patterns are added dynamically from a configura-tion file.

Node The node is a compound module: its only function is to contain its sub-modules. A node has an ID and a position.

PropagationModel There is one PropagationModel module. It models thereach of radio messages and routes messages between radios. If a radioswitches state to transmitting, radios within reach are informed of thisevent by the PropagationModel.

AreaManager The AreaManager module models real-world events happeningin the network. It generates these events and keeps track of their size(radius) and duration. It switches the active pattern modules in nodes onand off, depending on whether nodes are within an active area or not.

ScenarioManager The ScenarioManager reads a scenario configuration fileand dynamically creates all pattern modules within all nodes.

Each module in the model keeps and prints statistics. Besides, every modulecan optionally print debug messages. This made debugging the protocols much

easier: by making the MAC modules print debug messages, we could create acomplete trace of everything that happened in the network.

4.1.3 Protocol settings

In our experiments, we tested the S-MAC protocol with a frame length of onesecond, and with several lengths of the active time, varying from 75 ms to915 ms. For the T-MAC protocol, we always used a frame length of 610 ms(20000 ticks of a quartz crystal) and an interval TA with a length of 15 ms.The T-MAC protocol can optionally be deployed with overhearing avoidance,full-buffer priority, and FRTS. We show the best combination of these optionsin each experiment.

23


36/50

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

0 0.5 1 1.5 2 2.5

energ

yused[avg.mA/node]

load [msg / node / s]

Homogeneous unicast, msglength=20

CSMAS-MACT-MAC

75 ms

150 ms

305 ms

460 ms

610 ms

760 ms

915 ms

Figure 4.3: Homogeneous local unicast, with detail on the S-MAC line. Thenumbers indicate the length of the S-MAC active time per 1-second frame.

4.2 ResultsWe start with a simple benchmark, where network load is homogeneous. Wethen introduce experiments based on communication patterns and end with acomplete, realistic scenario.

Except for the complete scenario, we exercised all experiments with multiplenetwork loads. The load is on the horizontal axes of the graphs. The verti-cal axes show the energy usage in the network, since this is our main designcriterium.

Since throughput is not completely unimportant, we will end each graph atthe point where less than 90% of the messages are correctly received. In a multi-hop pattern, like nodes-to-sink, this means that we want 90% of all messages tofinally reach the sink node. We do not use the 90%-restriction for CSMA: since

CSMA has no built-in retransmits, it is far less reliable.The message lengths are data payload sizes, and do not include the MAC

header: 4 bytes for CSMA, 6 bytes for S-MAC and T-MAC.

Homogeneous local unicast (Figure 4.3) In this experiment, nodes sendpackets with 20 bytes of payload to their neighbors at random. Although thisis not a realistic communication pattern, it serves as a base case. For the T-MAC protocol, we used overhearing avoidance, but no FRTS and no full-bufferpriority mechanism.

In Figure 4.3, we can clearly see that CSMA provides no energy saving.The energy consumption when idle is 4 mA (the current drawn by the radio in

24


37/50

receive mode), slightly going up when more messages are sent.

For the S-MAC, various lines are shown for different lengths of the activetime. An additional line is drawn, which connects the S-MAC graphs that usethe least energy for each load. So on this line, the S-MAC protocol is tuned toprovide at least 90% throughput while using as little energy as possible for eachindividual load. From now on, we will only show similarly tuned lines for theS-MAC protocol.

We expect that this homogeneous experiment is the best case for the S-MACprotocol, since the load is homogeneous in both time and location. We see thatthe T-MAC protocol performs at least as well as the (per load tuned) S-MACprotocol.

The fact that the T-MAC protocol uses even less energy than S-MAC is dueto the fact that we tested the S-MAC protocol only with a limited number ofdiscrete lengths of the active time. To get an optimal parameter value for eachload, the S-MAC protocol would require complicated tuning, as it would in realdeployment. The adaptive behavior of T-MAC, on the other hand, requires noexplicit tuning.

Nodes-to-sink communication (Figure 4.4) In this experiment, nodes sendmessages to a single sink node at the corner of the network. Messages arerouted from node to node with a (slightly randomized) shortest path algorithm.No data aggregation is used. For the T-MAC protocol, we used overhearingavoidance, the full-buffer priority mechanism, and the FRTS mechanism.

Figure 4.4 shows that T-MAC uses less energy than S-MAC. We expectedthis, because in nodes-to-sink communication the load varies with the locationof nodes: there is more traffic in the neighborhood of the sink node. The

experiment also shows that the maximum throughput of the T-MAC protocolis less than that of the S-MAC protocol. This is mainly due to variations onthe early sleeping problem as described in Section 3.5.

We can see in Figure 4.4 that the relative throughput of T-MAC, comparedto S-MAC, decreases when the messages are larger. In that case, the penalty ofthe early sleeping problem is higher.

Early sleeping problem (Figure 4.5) In this experiment, we show the ef-fectiveness of the measures addressing the early sleeping problem (Section 3.5).We see that the FRTS mechanism increases maximum throughput by approx-imately 75% (0.08 vs. 0.14 messages per second), at the cost of some energy.Adding the full-buffer priority mechanism adds approximately 30% (0.14 vs.

0.18 messages per second) without the cost of extra energy.

Event-based local unicast (Figure 4.6) We now proceed towards a morerealistic scenario. In this experiment, events occur in the network with a fre-quency of one per 10 seconds. Events have an average duration of 5 secondsand affect an area of approximately 9 nodes. These nodes then send local uni-cast messages to their neighbors for the duration of the event. A neighbor thatreceives one of these messages replies with a probability of 20%. We performedmultiple measurements, with different message frequencies during events. Thisfrequency is on the horizontal axis of the graph (Figure 4.6). For T-MAC, weused overhearing avoidance but no FRTS and no full-buffer priority.

25


38/50

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

0 0.05 0.1 0.15 0.2 0.25

energyus

ed[avg.mA/node]


Nodes-to-sink, msglenth=20

CSMAS-MACT-MAC

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

0 0.05 0.1 0.15 0.2 0.25

energyused[avg.mA/node]


Nodes-to-sink, msglength=100

CSMAS-MACT-MAC

Figure 4.4: Nodes-to-sink at moderate (20 bytes data) and larger (100 bytesdata) message length.

26


39/50

0

0.2

0.4

0.6

0.8

1

1.2

0 0.05 0.1 0.15 0.2

energy

used[avg.mA/node]


T-MAC nodes-to-sink, msglength=20

no measures

prio

FRTS

FRTS + prio

Figure 4.5: T-MAC options in a nodes-to-sink pattern.

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

0 1 2 3 4 5 6 7 8

energyused[avg.mA/node]

peak load [msg / node / s]

Event-based unicast, msglength=20

CSMAS-MACT-MAC

Figure 4.6: An event-based scenario, where active nodes exchange local unicastmessages.

27


40/50

0

0.5

1

1.5

2

2.5

3

3.5

4

CSMA S-MAC T-MAC

Event triggered reporting

ene

rgyused[avg.mA/node]

Figure 4.7: A complete scenario with both periodic reporting and event-basedmessages.

Figure 4.6 shows that T-MAC uses much less energy than either S-MAC orCSMA, especially when the message frequency during events increases. How-ever, the maximum frequency that T-MAC can handle is lower than that ofS-MAC, like we have seen in the nodes-to-sink communication pattern. Again,T-MAC suffers from the early sleeping problem, because we have relatively manyedge nodes.

Event-based local unicast and node-to-sink reporting (Figure 4.7) Thisis an experiment with a complete scenario. When no events happen, nodesexchange local messages of 10 bytes with each other every 20 seconds. Theyalso report to a sink node every 100 seconds. When an event happens (onceevery 10 seconds, like in the previous experiment), nodes in the neighborhood ofthe event start sending local unicast messages of 30 bytes, with a rate of 4 persecond. They then also send messages of 50 bytes to the sink, once per second.These messages are aggregated in the network.

To be able to handle this kind of traffic, we had to tune S-MAC to listen forat least 715 ms in every second. For the T-MAC protocol, we used overhearingavoidance, but no FRTS and no full-buffer priority.

Figure 4.7 clearly shows the disadvantage of a fixed-length active part: to beable to handle a short-lived burst of trafficeven though that happens relativelyseldomthe deployer of S-MAC must choose a long active part of the dutycycle. S-MAC therefore wastes much energy at times when no events happen.By adaptively changing the duty cycle, T-MAC can decrease the used energyin this scenario by a factor 5.

28


41/50

Chapter 5

Real-world experiments

In this chapter, we report our experiences with the actual implementation ofthe T-MAC protocol. We start by presenting the operating environment. Thenwe describe the implementation of the T-MAC protocol and the variations be-tween the theoretical and the real implementations. We end with some powermeasurements.

5.1 Operating environment

To implement and test the T-MAC protocol on the real EYES nodes, we neededsome basic operating system. Since the EYES hardware is new, no such oper-ating system existed yet. We had three choices:

1. wait for the end of a project at the University of Twentethis projecthad the creation of an OS for the EYES nodes as a goal;

2. port the popular TinyOS [15], used for wireless sensor research at Berkeley,to the EYES nodes;

3. create a simple operating system from scratch, with minimal functionalityto test the MAC and to print debug messages on the serial port.

The OS project in Twente was quite elaborate and would not be finished beforewe needed it. The TinyOS system is too simple for our testing purposes andporting it would, in our opinion, be more work than writing an operating systemthat was designed specially for the EYES hardware. We therefore decided to goour own way.

Although the core OS has been implemented within a week, functionalityhas been added when needed. In the end, we had a usable system that mayserve as a stable base for future expansion. Features are:

support for both event-based and thread-based (blocking) programmingmodels;

multi-threading: multiple threads can exist;

an event signalling system for communication between event-based partsand thread-based parts, or between multiple threads;

29


42/50

low-power: whenever all threads are blocking, and no event-based program

parts run, the CPU is immediately put in low-power mode; a customizable number of low-resolution (10 ms) timers;

support for 6 real-time (30 s) timers;

complete buffered serial port handling;

networking: radio control, data frame modulation, demodulation, CRCchecks, MAC layer;

control of transmission power through the on-board digital potentiometer;

low-power radio data handling using the UART and start edge detection;

control of the on-board EEPROM: erase, read, write; flash memory control: self-programming and information memory update;

support for reading AD-converter values (like the RSSI signal);

support for an optional infrared sensor;

leanness: the complete OS, including wireless networking (T-MAC) codeand buffers (network, serial port), uses approximately 16 KB of code and416 bytes of RAM of the available 60 KB ROM and 2 KB RAM; theT-MAC protocol implementation itself uses only 42 bytes of state.

As a side project to the theoretical work and simulations, the design and im-plementation of this little operating system was both a learning and pleasing

distraction. We learned much about the actual hardware, and some of it couldbe fed back into the simulation model.

5.2 Implementation issues

We did not implement all features of the T-MAC protocol onto the EYEShardware. To test the effectiveness of the full-buffer-priority and future-RTSschemes, a large-scale experiment is needed, involving a lot of nodes. Sincethere was no time do such an experiment, implementation of these features wassenseless.

We have also not implemented the possibility to keep multiple schedules yet.Although this is fairly easy to implement, we have only tested with single-clusterconfigurations.

During testing, we noted that the nodes schedules would drift apart relativelyfast. Even though the time-keeping on all nodes is based on ticks of a quartzcrystal, some of the nodes became unreachable within as little as 10 minutes.We had not simulated this effect.

To solve the drift problem, we used a simple correction scheme: when a nodereceives a SYNC message that contains almost, but not exactly, its own schedule,the node adjusts its own schedule towards the received schedule. To allow aconverging situation, the schedule is only adjusted for 50% of the differencebetween the two schedules.

30


43/50

The drift correction solved the problem: an experiment showed that nodes

were still perfectly synchronized after more than 10 hours.

The final implementation performs well. When sending a continuous stream ofdata messages, the nodes rarely go to sleep. But when no messages are sent, theindication LEDs on the nodes blink peacefully. The radio is then in the receivemode for 15 ms out of every 610 ms, which is less than 2.5% of the time.

5.3 Power usage

After the implementation of the T-MAC protocol, we performed a number ofpower usage experiments.1 In these experiments, one node was sending, anotherreceiving. We measured the power consumption of both the sending and the

receiving node. The message length is 20 bytes.To measure the power usage, we inserted a small resistor into the electrical

circuit. The voltage over the resistor is a measure for the electrical current. Thisvoltage was measured using specialized equipment, which sent the values to acomputer. At the computer, we captured the values. After precise calibration,we could measure the electrical current through the node with a precision ofapproximately 15 A. The sample rate was 500 Hz (limited by the PC software).

Figure 5.1 shows a power usage trace of an idle node. The power consump-tion is low most of the time. At regular intervals (0.61 seconds, the frame time)we see spikes to 4 mA. These are the active times, during which the radio ison. We also see two higher spikes. These are SYNC packet transmissions. InFigure 5.2 we see a power trace of a node receiving approximately one message

per second. There is a transmission in most frames, but the radio is still insleep mode most of the time. The high spikes are caused by transmitting CTSs.In Figure 5.3 we see a node that transmits messages at maximum rate. It isclear that this node never sleeps, as it should not. Instead, it toggles betweenreceive (3.75 mA) and transmit (18 mA). Figure 5.4 shows a closeup of a nodetransmitting 3 messages during a single frame.

The traces show that the current during transmission peaks between 18and 20 mAwhile it should be around 10 mA (max 12 mA) according to theradio specifications. The difference may be due to a short startup spike, or tothe radio not behaving within the specifications. The traces were too coarse-grained to determine the exact cause of these spikes. The spikes are interesting,since we used an average transmit current of 10 mA in the simulation model.If this current is in fact higher, the evaluation the MAC protocols could bewrongit would be biased in favor of protocols that allow more control packetsand retransmissions to save radio listening time. The current while receivingaverages between 3.75 and 4 mA, which is according to the specifications.

Table 5.1 shows the average power usage during each experiment. Wecan see that transmitting nodes use significantly more energy than receivingnodes. This is logical, since transmitting with our radio takes more power than

1In this section, we use the term power instead of energy to emphasize that we are talkingabout actual electrical characteristics. In strict sense, the terms are mostly interchangeable:power is energy divided by time. We also speak of power usage, or energy consumption, whenwe should strictly say electrical current. This is permitted, since the voltage is constant (joulesare consumed at a rate of (I 3V) per second). To re-cap: dE/dt = P = V I.

31


44/50


45/50

0

2

4

6

8

10

12

14

16

18

20

0 2 4 6 8 10

current[mA]

time [s]

Figure 5.3: Power usage trace, transmitting node, full speed.

0

5

10

15

20

25

6.18 6.2 6.22 6.24 6.26 6.28

current[mA]

time [s]

RTS

CTS

DATA RTS DATA RTS DATA

ACK

CONTEND

CONTEND

CTS CTSACKACK

CONTEND

TA

Figure 5.4: Power usage trace, transmitting node, 10 messages / second.

33


46/50

msg / s transmit mA receive mA

0 0.138 0.1381 0.400 0.246

10 1.516 0.890max 9.590 7.473

Table 5.1: Average energy consumption of sending and receiving EYES nodes(T-MAC protocol).

receiving. More importantly, we see that the idle power usage (0.138 mA)is less than 4% of the power usage of a non-energy saving protocol (whichwould be between 3.75 and 4 mA). This is well above the theoretical limit(TA/Tframe = 15ms/610 ms = 2.5%). However, the theoretical limit only takes

the radio energy usage into account, not the CPU, EEPROM, RS232 voltageconverter and other components. We think that 96% overall energy savings isa very good result.

34


47/50

Chapter 6

Conclusions and future

work

We have presented T-MAC, a MAC protocol for wireless sensor networks, whichsaves energy by turning off the radio as much as possible. The moment to turnoff the radio is determined by a time-out.

The main conclusion that we can draw from this research is that, indeed,time-outs present a simple but effective way to address the idle listening problemin an environment with variable network traffic load. Implementation of the ideawith the T-MAC protocol has shown the advantages, both in simulation and onreal hardware: during a high load, nodes will communicate without sleeping,but during a very low load nodes will use their radios for as little as 2.5% of thetime, saving as much as 96% of the energy compared to a traditional protocol.

The T-MAC protocol can easily be implemented. The final implementationof the protocol itself requires no more than 42 bytes of state.

The time-out scheme, as implemented by the T-MAC protocol, uses significantlyless energy than a scheme with a fixed duty cycle, such as the S-MAC protocol,when applied to an environment with varying message rates. The exact advan-tage depends mainly on the amount of variation in the message rate. Even in ahomogeneous, non-varying environment the T-MAC protocol can be advanta-geous, since it requires no tuning to the specific message rate, while the S-MACprotocol must be tuned precisely for optimal energy savings. Deployment of theT-MAC protocol can therefore be faster.

Simulations of the T-MAC protocol have shown a new problem: the early sleep-ing problem, which decreases throughput dramatically in an asymmetric com-munication pattern. We have presented two solutions that increase the through-put by more than 100%, but it is still less than optimal. This is a trade-off tothe adaptiveness of the protocol. However, we do not expect such very highmessage rates in wireless sensor networks.

We have encountered the early sleeping problem only in a perfect, simulatedworld. It may well be the case that the problem does not exist when nodes arespread more randomly, or have more neighbors. Or maybe the problem becomesmuch worse, making the T-MAC protocol unusable. Future work is needed to

35


48/50

determine the seriousness of the early sleeping problem, both in a more realistic

simulation setting and in large-scale experiments with real hardware. Theseexperiments should also test the effectiveness of the proposed solutions.

We have only experimented with a static, non-mobile network. We expect prob-lems when applying virtual clustering to groups of mobile nodes. The virtualclustering technique, proposed in the S-MAC protocol and re-used in the T-MAC protocol, has not been researched thoroughly. Since the T-MAC protocolleans heavily on some kind of synchronization, the clustering is important. Moreresearch should be done on virtual clustering, and on multi-hop synchronizationin general, both in static and in mobile networks.

36


49/50

Bibliography

[1] V. Bharghavan, A. Demers, S. Shenker, and L. Zhang. MACAW: a mediaaccess protocol for wireless LANs. In Proceedings of the conference onCommunications Architectures, Protocols and Applications, pages 212225,London, 1994.

[2] Deborah Estrin, Ramesh Govindan, John S. Heidemann, and Satish Ku-mar. Next century challenges: Scalable coordination in sensor networks. InFifth Annual ACM/IEEE International Conference on Mobile Computingand Networks (MobiCOM 99), pages 263270, Seattle, Washington, USA,August 1999.

[3] P.J.M. Havinga and G.J.M. Smit. Energy-efficient TDMA medium ac-cess control protocol scheduling. In Proceedings Asian International MobileComputing Conference (AMOC 2000), pages 19, November 2000.

[4] Phil Karn. MACA - a new channel access method for packet radio. InProceedings of the 9th ARRL Computing Networking Conference, 1990.

[5] LAN MAN Standards Committee of the IEEE Computer Society. IEEE Std802.11-1999, Wireless LAN Medium Access Control (MAC) and PhysicalLaer (PHY) specifications. IEEE, 1999.

[6] RFM. TR1001 868.35 MHz Hybrid Tranceiver.

[7] RFM. ASH Transceiver Designers Guide, October 2002.

[8] S. Singh and C.S. Raghavendra. PAMAS: Power aware multi-access pro-tocol with signalling for ad hoc networks. ACM SIGCOMM Computer

Communication Review, 28(3):526, July 1998.

[9] M. Stemm and R. H. Katz. Measuring and reducing energy consumptionof network interfaces in hand-held devices. IEICE Transactions on Com-munications, E80-B(8):11251131, 1997.

[10] Texas Instruments. MSP430x1xx Family Users Guide. SLAU049B.

[11] Y. Tseng, C. Hsu, and T. Hsieh. Power-saving protocols for IEEE 802.11-based multi-hop ad hoc networks. In Twenty-First Annual Joint Confer-ence of the IEEE Computer and Communications Societies (INFOCOM),volume 1, pages 200209, June 2002.

37


50/50

[12] A. Varga. The OMNeT++ discrete event simulation system. In European

Simulation Multiconference (ESM2001), Prague, Czech Republic, June2001.

[13] W. Ye, J. Heidemann, and D. Estrin. An energy-efficient MAC protocol forwireless sensor networks. In Twenty-First Annual Joint Conference of theIEEE Computer and Communications Societies (INFOCOM), volume 3,pages 15671576, June 2002.

[14] http://eyes.eu.org

[15] http://webs.cs.berkeley.edu/tos/

Documents

Giao Thuc T-MAC Cho Mang Cam Bien Khong Day