scribes my graduation project on a MAC protocol for wireless sensor networks. .... The use of a wireless network has several advantages when compared to a.
J.M. van Dam
An Adaptive Energy-Efficient MAC Protocol for Wireless Sensor Networks June, 2003
J.M. van Dam
An Adaptive Energy-Efficient MAC Protocol for Wireless Sensor Networks
Afstudeerverslag Auteur Studienr. Richting Datum
: : : :
J.M. van Dam 9170094 parallelle en gedistribueerde systemen 13 juni 2003
Basiseenheid Parallelle en Gedistribueerde Systemen Faculteit Electrotechniek, Wiskunde en Informatica Technische Universiteit Delft
ii
Afstudeergegevens Afstudeervoordracht Parallelle en Gedistribueerde Systemen Spreker: Onderwerp:
Tijs van Dam Een energie-efficient MAC protocol voor draadloze sensornetwerken Datum: 13 juni 2003 Tijd: 15.00 Plaats: TU Delft, Gebouw Elekrotechniek, Mekelweg 4, Zaal E AfstudeerProf.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 een of 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
iv
Preface This report represents the end of a decade at the University of Delft. It describes 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 interesting subject. The field is very diverse, and much ground has not been covered yet. My work included, among other things, theoretical experiments in a discrete event simulator, but also the calculation of a maximum bit run length in a signal, based on capacitator values. All of this was new to me, and I have had a fun time exploring all the technologies. This project was part of the Consensus project, a joint project of the University of Delft and the University of Twente. The project focuses on ubiquitous computing, and especially on sensor networks. The meetings with the people from Twente have added positively to the experience. I would like to thank Niels and Koen for their continuous input. I would also like to thank Ivaylo for helping out with the power measurements. And of course Lex Winter for the great merguez sausages. . . Tijs van Dam Den Haag, June 2003
v
vi
Contents Afstudeergegevens
iii
Preface
v
Abstract
ix
1 Introduction 1.1 The EYES hardware . . . . . . . 1.2 the MAC layer . . . . . . . . . . 1.3 Communication patterns . . . . . 1.4 Problem description and research
. . . .
1 2 3 4 5
2 Background and related work 2.1 Traditional MAC protocols . . . . . . . . . . . . . . . . . . . . . 2.2 Energy saving solutions . . . . . . . . . . . . . . . . . . . . . . . 2.3 The S-MAC protocol . . . . . . . . . . . . . . . . . . . . . . . . .
7 7 9 10
3 The 3.1 3.2 3.3 3.4 3.5
13 13 14 15 15 17
T-MAC protocol Main design criterium . . . . . Basic protocol . . . . . . . . . . Clustering and synchronization Tuning and additional features Asymmetric communication . .
. . . . .
. . . . . . . . . goal
. . . . .
. . . . .
. . . . .
. . . .
. . . . .
. . . .
. . . . .
. . . .
. . . . .
. . . .
. . . . .
. . . .
. . . . .
. . . .
. . . . .
. . . .
. . . . .
. . . .
. . . . .
. . . .
. . . . .
. . . .
. . . . .
. . . .
. . . . .
. . . .
. . . . .
. . . .
. . . . .
. . . .
. . . . .
. . . . .
4 Simulation experiments 21 4.1 Simulation setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5 Real-world experiments 29 5.1 Operating environment . . . . . . . . . . . . . . . . . . . . . . . . 29 5.2 Implementation issues . . . . . . . . . . . . . . . . . . . . . . . . 30 5.3 Power usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6 Conclusions and future work
35
vii
viii
Abstract Wireless sensor networks are collections of sensors that are equipped with a radio and form a wireless network together. The main advantages of wireless sensor networks are fast and easy deployment, and low maintenance cost. Energy is a scarce resource in such networks, which has a great impact on the design of hardware and software. The hardware is cheap and limited. Software is specialized; network protocols must be designed for sensor communication patterns and focus on low energy consumption. The easiest way to reduce energy consumption is to turn off the radio when it is not needed. We present the T-MAC protocol, a medium access control protocol designed specially for wireless sensor networks. T-MAC lets wireless sensor nodes turn on their radio at synchronized times, and turn them off after a certain time-out— when no communication occurs during some time. Messages are transmitted in bursts. This scheme allows dynamic adaption of the radio-on time to changing message 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 nodes turn 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, but it is still less than 70% of the maximum throughput of other protocols. This is a trade-off to the adaptiveness of the protocol. However, we do not expect such high message rates in wireless sensor networks. Simulation experiments have shown that the T-MAC protocol reduces the energy used by the radio with as much as 80%, in a typical scenario and compared to classical protocols like CSMA. The S-MAC protocol saves only 30% in this scenario, after optimal tuning. Implementation of the T-MAC protocol on real wireless sensor hardware has shown 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 situation with 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 is simple and uses only 42 bytes of state.
ix
x
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 station. The control station receives the sensor data and performs some kind of processing: recording the data, comparing data from different sensors, ringing an alarm, etc. Wireless sensor networks [2] communicate via a radio interface instead of being wired to a control station (Figure 1.1). Sensors themselves are normally not equipped with a radio interface. Therefore, a simple signal processor and a radio are packaged together with one or more sensors into what is called a wireless sensor node. The sensor is used to perform measurements and the radio to transmit these measurements to interested parties. The processor is needed to drive the sensors and the radio—we would not want a continuous radio signal; to save energy and because of radio transmission regulations, radio transmission should only take place periodically, or when measurements exceed some threshold. The use of a wireless network has several advantages when compared to a traditional, wired network: • since no wires have to be placed, deployment can be extremely fast; urban warfare situations and temporary, short-term security are examples; • deploying and maintaining a network of wires is costly; at some point the added 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
• in some situations it may not be feasible to wire the network; think for example of forest fire detection or other environmental measurements— wireless sensor nodes could even be dropped from an airplane; Wireless sensor nodes can be powered by batteries, or some form of ambient energy (e.g. temperature differences). Since batteries have only a limited capacity, and ambient energy is limited itself, energy consumption is central in the design of wireless sensor hardware and software. Relevant issues are: Different trade-offs In most wireless networks, hardware and software are designed to maximize network throughput and to minimize latency. In wireless sensor networks, these are less important. The trade-off of throughput and latency versus energy usage is different, resulting in different, specialized network protocols. Multi-hop To minimize radio energy usage, the radio sending capacity is limited. To bridge large distances, messages must travel multiple hops to reach their destination. Nodes must be able to relay messages for other nodes. Ad-hoc We expect wireless sensor networks to live on their own: each node is equal (although some may be more equal than others) and there is no central, high power base station to regulate traffic. This is called ad-hoc networking. Send only important messages Since sending messages costs energy, the number of messages sent must be kept to a minimum. This means that only important messages are sent. For example, instead of sending a sensor measurement every second, we can choose to send a message only when the measurement exceeds a threshold. Local processing The advantage of having a processor with each sensor is that we can use it to perform some extra processing. For example, it is possible to calculate the daily average of some sensor data, and to send only the average. If the average is all we need, we still get all relevant information, while reducing the amount of messages. In-network processing It is likely that real-world events will be noticed by several sensor nodes. Instead of each node transmitting a message to a control station—which may be tens of hops away—, nodes can confer locally and agree that only one of them sends a message—the processing in this case is some distributed algorithm. Another form of in-network processing is data aggregation, whereby messages from different nodes are combined by relaying nodes. For example, the relaying node could relay only 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. Therefore, they generally have very limited hardware. To make the reader comfortable with the capacities of wireless sensor hardware, we will elaborate on a specific wireless sensor node design: the EYES nodes (Figure 1.2). These nodes have 2
Sensor I/O Radio
RS232 CPU
Antenna
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 is based on these nodes. The main components of the EYES nodes are: CPU The processor is a 16-bit Texas Instruments MSP430F149 [10], which runs at about 5 MHz. It has only 2 KB of RAM and 60 KB of program memory (ROM). It also has two internal UARTs, which can buffer a byte of data and allow the processor to work on bytes instead of bits—allowing the processor to do other work, or sleep, between bytes. The UARTs are used 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 bits per second. It requires a DC-balanced signal and is connected to one of the UARTs of the processor. The transmit signal goes through a digital potentiometer to adjust the transmit power. The radio uses approximately 10 mA while transmitting, 4 mA while listening/receiving and 20 µA in sleep mode. Note that listening costs 200 times as much energy as sleeping. EEPROM The node has a 256 KB EEPROM module, which can be serially written 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-term data like program modules. Serial port The other UART of the processor is, via a voltage converter, connected to a serial RS232 interface. This is useful for printing debug messages and interfacing with programs on a PC. The component that consumes the most energy is the radio. An important aspect of the radio is that having it in listen/receive mode costs almost half as much energy as when it is transmitting. This is typical for wireless hardware [9]. The processor specifications (2 KB RAM, 60 KB program) may seem very minimal, but, in fact, the EYES hardware is quite generous compared to some other sensor nodes that have been developed [15].
1.2
the MAC layer
Since trade-offs in wireless sensor networks are different than in ordinary wireless networks, and since hardware is much more limited, specialized network 3
Figure 1.3: Communication patterns: (event-based) local unicast and nodes-tosink 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. In wireless communication, a link consists of two nodes directly communicating via the radio. Part of the responsibility of the data link layer is to determine which node may access the medium at what time. We commonly refer to this task as medium access control (MAC). It is especially important in a shared medium—like the air—, since multiple nodes transmitting at the same time will interfere each other’s communication. Since a network contains multiple independent nodes, an agreement is needed for medium access control. This agreement should be shared by all nodes in the network. 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 lost messages. In a wireless environment, the MAC protocol determines the state of the radio on a node—sending, receiving, or sleeping. Since the radio, while listening or transmitting, uses relatively much energy, the MAC is a good place to save energy. A MAC protocol for wireless sensor networks should focus on energy usage, 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 the kind of traffic they have to handle. We have identified two main communication patterns in sensor applications (Figure 1.3): Local unicast/broadcast When a real-world event in the network occurs, we expect nodes to perform some in-network processing. This will generally involve 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 directed to one or a few sink nodes, which are hooked up to a fixed network or a computer—like a control board in a wired sensor network. Messages from different nodes may, or may not, be aggregated along the way. In this communication pattern, we see a more or less unidirectional flow of messages through the network. 4
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 determined that this communication pattern does not occur. We also assume that nodes are not moving. This is true for all applications we have identified. Future applications, or expansion of wireless sensor technology into other fields, may yield moving nodes. However, we do not take this into account. The two basic communication patterns imply that the message rate in the network may vary, both in time and location: events trigger periods of increased activity, 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 a node does not know when it will be the receiver of a message from one of its neighbors, it must keep its radio in receive mode whenever it is not transmitting. Consider, for example, a sensor application that requires nodes to exchange messages with their neighbors at an average rate of one per second. Messages are fairly short: they take less than 5 milliseconds to transmit. This results in each node spending an average of 5 ms per second on transmitting, 5 ms on receiving a message from another node, and 990 ms on listening while nothing happens. The radio is then idle listening, doing nothing useful, for 99% of the time. The goal of this research is to design a MAC protocol for wireless sensor networks that minimizes energy usage, while considering wireless sensor communication patterns and hardware limitations. We will mainly focus on reducing idle 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 existing MAC protocols and energy-saving solutions. We have implemented some protocols in a simulation program to compare them and study them better. Then we have designed a new protocol, T-MAC, partly based on an existing MAC protocol for wireless sensor networks. We have implemented this protocol in the simulator as well. After identifying and solving some problems, we have implemented and tested most of the protocol on the actual EYES hardware.
5
6
Chapter 2
Background and related work In this chapter we will present some of the theoretical background of this research. We will start with a classification of traditional MAC protocols, their problems and the way these have been solved. Then we will present MAC-related energy saving solutions that have been proposed until today. Finally, we will describe 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: protocols 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 let each node at its turn transmit a message. When the message has ended, the next 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 tokenpassing in wireless networks. Another way is to divide the time into frames of a certain length, and to divide each frame into slots. Each slot is owned by a certain node. A node can only send in its own slot. This method is known as Time Division Multiple Access (TDMA) and is widely used in wireless communication—especially when there is a central base station that can be in charge of slot allocation. The second category consists of MAC protocols that allow more nodes to access the medium at the same time. Collisions may then occur, but are dealt with. 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 that the 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. The contention period decreases the probability that two nodes start sending at the same moment and is therefore very important. Every protocol that allows multiple nodes to send at the same time features such a contention period. These protocols are therefore also known as contention-based protocols. 7
A
C
B
Figure 2.1: The hidden terminal problem. Nodes A and C are out of each others reach.
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 protocols. In a multi-hop, ad-hoc network, like wireless sensor networks, slot allocation becomes a two-hop graph coloring problem (a node can re-use a slot when none of its two-hop neighbors uses it). This problem is complex and requires efficient coordination—especially in denser networks. Furthermore, as TDMA divides time into small slots, exact timing is important. Time synchronization becomes a critical aspect.
2.1.1
The hidden terminal problem: MACA
Traditional CSMA, when applied to a multi-hop wireless network, suffers from a classic problem: the hidden terminal problem. It stems from the fact that, in wireless communication, collision happens at the receiver [4]. Two nodes that are out of each others reach could be transmitting to a third node in the middle (Figure 2.1). The middle node will receive neither message, since the transmissions interfere with each other. Carrier sensing does not help in this case, since that happens at the sender: the two sending nodes both perceived the air as clear before they started sending. Another problem is the exposed terminal problem. In Figure 2.2, node B is sending to node A. Node C will defer sending to node D, because it waits for B’s transmission to end. However, since D is out of the reach of B’s transmission, there would be no interference at the receiver and therefore no problem. Some of the possible throughput is lost by C’s waiting. Both these problems are addressed by the Multiple Access with Collision Avoidance (MACA) scheme [4]. In this scheme, the node that needs to transmit a message sends a small Ready-To-Send (RTS) message to the receiver. The receiver immediately responds with a Clear-To-Send (CTS) message. After receiving the CTS, the sender will transmit the data message. Both the RTS and the CTS messages carry the length of the data message. When a node overhears an RTS message destined for another node, it is prohibited from sending during the time needed for the other node to send a CTS message. A node that overhears a CTS message is prohibited from sending during the time needed to transmit the data message. No carrier sensing is used. 8
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 the CTS from the receiver of the message and remain silent. The RTS and CTS messages are very small and therefore unlikely to collide. The exposed terminal problem is also solved: a node that receives an RTS message, but not the corresponding CTS message, is allowed to transmit. For history’s sake we should acknowledge that the RTS/CTS scheme was first used by the Apple Localtalk network. The reason was that the communication chip in the Apple Macintosh could only buffer three bytes. The RTS, which could fit into the buffer, gave the receiver a chance to allocate buffer space and get the CPU ready to receive the data. The creators of the protocol recognized the collision avoidance advantage (although this network was mainly used in a single cell without hidden terminals) and named it CSMA/CA (CSMA with collision avoidance). Phil Karn, who described MACA, recognized that this scheme was the solution for the hidden and 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 improvements to the MACA protocol [1]. Most importantly, an acknowledgement was introduced. After sending the data packet, the receiver responds with a small ACK message. If the sending node does not receive the ACK, it can retry the operation. This way, reliability is built into the protocol, which is advantageous in unreliable 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. Its purpose was mainly to wirelessly connect portable computers and PDAs. Furthermore, although multi-hop networks and interference have been a design issue, the IEEE 802.11 protocol was designed mainly for single cell networks. Since the exposed terminal problem is not a big problem, and since the RTS/CTS mechanism does not always perfectly avoid collisions, IEEE 802.11 re-introduces medium sensing. The advantage of medium sensing was considered more important than the exposed terminal problem.1
2.2
Energy saving solutions
Several solutions exist that address the problem of energy waste due to idle listening. Each solution allows the node to turn off its radio at times. We can broadly specify three classes of solutions: TDMA-based, special hardware, and contention-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 that nodes only have their radio on during ‘their slot’. This way, during periods of 1 The
exposed terminal problem was described by Phil Karn in terms of relay stations on top of hills, which were obstructed from communicating with local stations by another far-away relay station [4].
9
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 beginning of a slot can be an announcement phase. During this phase, other nodes may announce themselves. If no announcements take place, and the owner of a slot has no message to send, it can turn off its radio immediately [3]. However, as we have already determined, this requires much complexity and critical timing in the nodes. We think that TDMA-based protocols require too much for the current cheap hardware.
2.2.2
Special hardware
A promising energy-saving solution is to use special signalling hardware to announce relevant communication. A node can turn on its radio after having been signalled. 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 the radio used for communication [8]. It may seem strange to use a radio to allow shutting down another radio, but we need to keep in mind that the wake-up radio is only used for signalling. No data processing is required, which means that the receiver can be very simple and requires much less energy than the hardware used for data communication. Although the wake-up radio is a promising solution, most wireless sensor nodes currently used in research are not equipped with extra radios—and the EYES 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-band signalling, nodes must agree to periodically sleep, and buffer messages until the next active period. The IEEE 802.11 protocol—in ad-hoc mode—has 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 traffic indication maps (TIMs) are exchanged, which indicate to nodes that they must stay awake to receive messages. Unfortunately, this protocol was designed with the presumption that all nodes are located in a single network cell, while wireless sensor networks will generally be multi-hop. Adaptions for multi-hop networks have 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 designed for wireless sensor networks. This is the protocol we used as a base for our 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 contention-based protocol for sensor networks. The basic idea is that time is divided into—fairly large—frames. Every frame has two parts: an active part and a sleeping part. During the sleeping part, a node turns off its radio to preserve 10
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 together. energy. During the active part, it can communicate with its neighbors and send any messages queued during the sleeping part, as shown in Figure 2.3. Since all messages are packed into the active part, instead of being ‘spread out’ over the whole frame, the time between messages, and therefore the energy wasted on idle listening, is reduced. S-MAC needs some time synchronization, but that is not as critical as in TDMA-based protocols: the time scale is much larger. Typically, there may be an active part of 200 ms in a frame of one second. A clock drift of 500 µs will not be a problem. The S-MAC protocol basically trades used energy for throughput and latency. Throughput is reduced because only the active part of the frame is used for communication: the remaining throughput scales linearly with the fraction of the active part within the frame. Latency increases because a messagegenerating event may occur during sleep time. In that case, the message will be queued 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 a CTS destined for another node: the overhearing node is prohibited from using the medium during a certain time, so it may turn off the radio as well. This feature is called overhearing avoidance. S-MAC has two important parameters: the total frame time, which is limited by latency requirements and buffer space, and the active time. The active time depends mainly on the message rate: it can be so small that nodes are able to transfer all their messages within the active time.
11
12
Chapter 3
The T-MAC protocol In this chapter, we will describe the design of the T-MAC protocol. We will first present the main design criterium, and explain why the S-MAC protocol does not meet this criterium in an optimal way. After that, we will describe the basic scheme of the T-MAC protocol, followed by the virtual clustering technique used for synchronization. Then, we will add some protocol-specific settings 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 energy waste are: collisions if two nodes transmit at the same time and interfere with each others transmission, packets are corrupted. Hence, the energy used during transmission 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 for transmitting and receiving these packets as overhead; overhearing since the air is a shared medium, a node may receive packets that are not destined for it; it could then as well have turned off its radio. These other sources of energy usage are relatively insignificant when compared to 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 two—due to collisions 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 within the frame is dependent on the required throughput (Section 2.3). The problem is that, while latency requirements and buffer space are generally fixed, the message rate will usually vary (Section 1.3). If important messages 13
TA
TA
TA
TA
TA
TA
Figure 3.1: The basic T-MAC protocol scheme, with adaptive active times. are not to be missed—and unimportant messages should not have been sent in any case—, the nodes must be deployed with an active time that can handle the highest expected load. Whenever the load is lower than that, the active time is not optimally used and energy will be wasted on idle listening. The novel idea of the T-MAC protocol is to reduce idle listening by transmitting all messages in bursts of variable length, and sleeping between bursts. To maintain an optimal active time under variable load, we dynamically determine its length. We end the active time in an intuitive way: we simply time out on hearing nothing.
3.2
Basic protocol
Figure 3.1 shows the basic scheme of the T-MAC protocol. Every node periodically wakes up to communicate with its neighbors, and then goes to sleep again until the next frame. Meanwhile, new messages are queued. Nodes communicate with each other using a Request-To-Send (RTS), Clear-To-Send (CTS), Data, Acknowledgement (ACK) scheme, which provides both collision avoidance and reliable transmission (Section 2.1). A node will keep listening and potentially transmitting, as long as it is in an active period. An active period ends when no activation event has occurred for 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 node’s 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 an upper 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 the beginning of the frame. Since messages between active times must be buffered, the buffer capacity determines an upper bound on the maximum frame time. 1 Through
a Received Signal Strength Indication (RSSI) signal from the radio.
14
A B C D
Figure 3.2: Multiple schedules; nodes B and C, which form the border between two 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 by waiting and listening. If it hears nothing for a certain amount of time, it chooses a frame schedule and transmits a SYNC packet, which contains the time until the next frame starts. If the node, during startup, hears a SYNC packet from another node, it follows the schedule in that SYNC packet and transmits its own SYNC accordingly. Nodes retransmit their SYNC once in a while. Nodes must also listen for a complete frame sporadically, so they can detect the existence of different schedules. 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 from another node, it must adopt both schedules. It must also transmit a SYNC with 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 node will have an activation event at the start of both frames. This is depicted in Figure 3.2, where nodes B and C have double schedules, allowing them to act as border nodes between the virtual clusters A-B and C-D. Nodes must start a data transmission only at the start of their own active time. At that time, both neighbors with the same schedule, and neighbors that have adopted the schedule as extra, are awake. If a node would start transmission at the start of a neighbor’s frame, it might be transmitting to another, sleeping neighbor. Note that broadcasts only need to be transmitted once. 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 obviates the need to maintain information on individual neighbors. The virtual clustering technique is easy to implement. Keeping multiple schedules with a fixed-length active time is more complex, since active times may overlap.
3.4
Tuning and additional features
We will now discuss some (additional) features of the T-MAC protocol, which provide better tuning. 15
A
contend
RTS
CTS
DATA
ACK
B C
contend
TA
Figure 3.3: A basic data exchange. Node C overhears the CTS from node B and will not disturb the communication between A and B. TA must be long enough for 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 time within a contention interval after detecting a collision. Only when the air is clear during that time do they restart transmission. Usually, a back-off scheme is used: the contention interval increases when traffic is higher. The backoff scheme reduces the probability of collisions when the load is high, while minimizing latency when the load is low. In the T-MAC protocol, every node transmits its queued messages in a burst 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 a fierce fight for winning the medium every time it sends an RTS. An increasing contention interval is not useful, since the load is mostly high and does not change. Therefore, RTS transmission in T-MAC starts by waiting and listening for a random time within a fixed contention interval. This interval is tuned for maximum load. The contention time is always used, even if no collision has occurred yet.
3.4.2
RTS retries
When a node sends an RTS, but does not receive a CTS back, one of three things 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 go to sleep. However, that would be wrong in cases 1 and 2: we would then have a situation where the sending node goes to sleep, while the receiving node is still awake. Since this situation might occur even at the first message of the frame, the throughput would (and did, in our preliminary experiments) dramatically decrease. 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
A
contend
RTS
DATA
CTS
ACK
B C D
contend
active
sleep RTS?
TA
Figure 3.4: The early sleeping problem. Node D goes to sleep before C can send an RTS to it.
3.4.3
Determining TA
A node should not go to sleep while its neighbors are still communicating, since it may be the receiver of a subsequent message. Receiving the start of the RTS or CTS packet from a neighboring node is enough to trigger a renewed interval TA. Since a node may not hear, because it is not in range, the RTS that starts a communication with its neighbor, the interval TA must be long enough to receive at least the start of the CTS packet (Figure 3.3). This observation gives us 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 RTS packet, and T is the turn-around time (the short time between the end of the RTS packet and the beginning of the CTS packet). In our experiments, we used TA = 1.5 × (C + R + T ), which proved to be satisfactory. A larger TA increases the energy used.
3.4.4
Overhearing avoidance
The S-MAC protocol introduced the idea of sleeping after overhearing an RTS or CTS destined for another node. Since a node is prohibited from sending during that time, it can not take part in any communication and may as well turn 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 a side effect, collision overhead becomes higher: a node may miss other RTS and CTS packets while sleeping and disturb some communication when it wakes up. Consequently, the maximum throughput decreases; for short packets by as much as 25%. So although overhearing avoidance saves energy, it must not be used when maximum throughput is (at times) required.
3.5
Asymmetric communication
Preliminary experiments revealed a problem with the T-MAC protocol when traffic through the network is mostly unidirectional, like in a nodes-to-sink com17
A
contend
RTS
CTS DS
DATA
ACK
B C D
contend
active
active FRTS
RTS
TA
Figure 3.5: Future-request-to-send packet exchange. munication pattern. This problem is simplified in Figure 3.4. Each of the nodes A though D in the picture forms a cell with its neighbors. Messages flow from top to bottom, so node A sends only to B, B only to C, and C only to D. Now consider node C. Every time it wants to send a message to D, it must contend for 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 will reply with a CTS packet, which can also be heard by node D. In that case, node D will be awake when the communication between C and B ends. However, if node C looses contention because it overhears a CTS packet from B to A (see Figure 3.4), C must remain silent. Since D does not know of the communication between A and B, its active time will end, and node D will go to sleep. Only at the 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 either succeed or fail (by loosing to node A). Both of these events have equal probability. 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 sending two packets (it must succeed twice), etcetera, in each frame. We call the observed effect the early sleeping problem (since a node goes to sleep when a neighbor still has messages for it). In the nodes-to-sink communication pattern, the early sleeping problem reduced the total possible throughput of T-MAC to less than half of the maximum throughput of traditional protocols or S-MAC. In later experiments, we have also encountered this problem at the border 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 future request-to-send. The idea is to let another node know that we still have a message for it, but are ourselves prohibited from using the medium. It works as follows: if a node overhears a CTS packet destined for another node, it may immediately send a future-request-to-send (FRTS) packet, like node C in Figure 3.5. The FRTS packet contains the length of the blocking data communication (this information was in the CTS packet). A node must not send an FRTS packet if it senses communication right after the CTS, or if it is prohibited from sending due to a prior RTS or CTS. 18
A B C
contend
contend
contend RTS
D
RTS CTS
DATA
ACK
TA
Figure 3.6: Taking priority upon receiving RTS. A node that receives an FRTS packet knows it will be the future target of an RTS packet and must be awake by that time. The node can determine this from the timing information in the FRTS packet. As the FRTS packet would otherwise disturb the data packet that follows the CTS, 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 node that 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 data packet. Since the FRTS packet has the same size as a DS packet, it will collide with the 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 unidirectional communication patterns by 75%. However, due to the somewhat higher 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 more or less unidirectional communication pattern is expected. Note, however, that when the load is low, the number of exchanged packets, and therefore the increased overhead, is also low. Taking priority on full buffers The second solution is a scheme that we call full-buffer priority. When a node’s transmit/routing buffers are almost full, it may prefer sending to receiving. This means that when a node receives an RTS packet 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 has two effects. First, the node has an even higher chance of transmitting its own message, 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 the network, which is advantageous in a nodes-to-sink communication pattern; in Figure 3.6, node B is prevented from sending until node C has enough buffer space. We must, however, be careful with the full-buffer priority scheme, since it is 19
dangerous in a high-load situation where communication is not unidirectional. When all nodes in an omnidirectional communication pattern start taking priority, 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. This threshold guarded, in our experiments, the performance in an omnidirectional communication pattern, while still increasing the maximum throughput in a unidirectional pattern.
20
Chapter 4
Simulation experiments In this chapter, we will describe the protocol simulation. We will start by elaborating on our simulation setup and the model used. Then we will present the 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 the EYES wireless sensor nodes. The model has the same limits on clock resolution and precision, radio turn-around and wake-up times, and transmission bit rates as the EYES nodes do. Energy usage in the model is based on the amount of energy the real nodes use: 20 µA while sleeping, 4 mA while receiving and 10 mA while transmitting a DC-balanced signal [6, 7, 10]. Using these modeled nodes, we have built a network of 100 nodes in a 10 by 10 grid. We have chosen a radio range so that non-edge nodes all have 8 neighbors (Figure 4.1). We admit that this perfect world is not a realistic setup for most sensor networks, but it is easy implementable and a good start. Further research with a more complex network will be valuable.
4.1.1
Scenarios
Each simulation run follows some scenario. A scenario is defined as a superposition 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
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 network where all nodes periodically report to a single sink node, we could add a nodesto-sink pattern to our scenario, with realistic settings for message length and frequency. Furthermore, we define active areas. An active area models a real-life event in the network. Active areas appear with some configurable frequency and have some configurable lifetime and size. If we would want to model an fire detection system, where the start of a fire can be detected in a range of 4 meters, we could set active areas to appear with a very low frequency, a long lifetime, and a radius of 4. Nodes are active when they are within one or more active areas, and idle when they are not. This is used by the pattern instances. Pattern instances are either active or always-on. Active pattern instances only generate messages in active nodes. Always-on pattern instances always generate messages, independent of the active areas. We use active patterns to model event-triggered communication (detection) and always-on patterns to model event-independent communication (periodic reporting). Pattern instances are independent of each other, and generate messages independently. Multiple pattern instances may use the same communication pattern. For example, we could in a scenario have a ‘to-sink’ always-on pattern that generates one message every 10 seconds, and a ‘to-sink’ active pattern that generates 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 consists 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 this module. Mac This module is the MAC protocol. The actual implementation can be defined in a configuration file, allowing a different MAC protocol for each simulation run. The MAC module exchanges data packets with the AppSelector module, and data frames (e.g. RTS/CTS) with the radio module. Patterns One or more pattern modules exist in each node. These are the traffic-generating pattern instances described in Section 4.1.1. The pattern modules are the same in each node, based on the simulated scenario. AppSelector The AppSelector module sits between the MAC and the pattern modules. It queues packets for transmission (the MAC handles only one message at a time) and delivers received messages to the correct pattern module. This makes it possible for patterns to act on incoming messages— for example, to perform multi-hop message relaying. The AppSelector makes sure that a message from some pattern module ends up in the corresponding pattern module in the receiving node. 22
Node 2
Node 1
AreaManager P1
P2
P3
P1
P2
P3 ScenarioManager
AppSelector
AppSelector
MAC
MAC
Radio
Radio
Node 4
Node 3
Node n
PropagationModel
Figure 4.2: The simulation model in OMNeT++. Each block is an independent module. The communication patterns are added dynamically from a configuration file. Node The node is a compound module: its only function is to contain its submodules. A node has an ID and a position. PropagationModel There is one PropagationModel module. It models the reach of radio messages and routes messages between radios. If a radio switches state to transmitting, radios within reach are informed of this event by the PropagationModel. AreaManager The AreaManager module models real-world events happening in the network. It generates these events and keeps track of their size (radius) and duration. It switches the active pattern modules in nodes on and off, depending on whether nodes are within an active area or not. ScenarioManager The ScenarioManager reads a scenario configuration file and dynamically creates all pattern modules within all nodes. Each module in the model keeps and prints statistics. Besides, every module can optionally print debug messages. This made debugging the protocols much easier: by making the MAC modules print debug messages, we could create a complete 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 one second, and with several lengths of the active time, varying from 75 ms to 915 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 options in each experiment. 23
Homogeneous unicast, msglength=20 4.5
energy used [avg. mA / node]
4 915 ms
3.5 760 ms
3
610 ms
2.5 2
460 ms
1.5
305 ms
1 150 ms
0.5
CSMA S-MAC T-MAC
75 ms
0 0
0.5
1 1.5 load [msg / node / s]
2
2.5
Figure 4.3: Homogeneous local unicast, with detail on the S-MAC line. The numbers indicate the length of the S-MAC active time per 1-second frame.
4.2
Results
We start with a simple benchmark, where network load is homogeneous. We then introduce experiments based on communication patterns and end with a complete, realistic scenario. Except for the complete scenario, we exercised all experiments with multiple network loads. The load is on the horizontal axes of the graphs. The vertical axes show the energy usage in the network, since this is our main design criterium. Since throughput is not completely unimportant, we will end each graph at the point where less than 90% of the messages are correctly received. In a multihop pattern, like nodes-to-sink, this means that we want 90% of all messages to finally 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 send packets with 20 bytes of payload to their neighbors at random. Although this is not a realistic communication pattern, it serves as a ‘base case’. For the TMAC protocol, we used overhearing avoidance, but no FRTS and no full-buffer priority 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
receive mode), slightly going up when more messages are sent. For the S-MAC, various lines are shown for different lengths of the active time. An additional line is drawn, which connects the S-MAC graphs that use the least energy for each load. So on this line, the S-MAC protocol is tuned to provide at least 90% throughput while using as little energy as possible for each individual load. From now on, we will only show similarly tuned lines for the S-MAC protocol. We expect that this homogeneous experiment is the best case for the S-MAC protocol, since the load is homogeneous in both time and location. We see that the T-MAC protocol performs at least as well as the (per load tuned) S-MAC protocol. The fact that the T-MAC protocol uses even less energy than S-MAC is due to the fact that we tested the S-MAC protocol only with a limited number of discrete lengths of the active time. To get an optimal parameter value for each load, the S-MAC protocol would require complicated tuning, as it would in real deployment. The adaptive behavior of T-MAC, on the other hand, requires no explicit tuning. Nodes-to-sink communication (Figure 4.4) In this experiment, nodes send messages to a single sink node at the corner of the network. Messages are routed from node to node with a (slightly randomized) shortest path algorithm. No data aggregation is used. For the T-MAC protocol, we used overhearing avoidance, the full-buffer priority mechanism, and the FRTS mechanism. Figure 4.4 shows that T-MAC uses less energy than S-MAC. We expected this, because in nodes-to-sink communication the load varies with the location of nodes: there is more traffic in the neighborhood of the sink node. The experiment also shows that the maximum throughput of the T-MAC protocol is less than that of the S-MAC protocol. This is mainly due to variations on the early sleeping problem as described in Section 3.5. We can see in Figure 4.4 that the relative throughput of T-MAC, compared to S-MAC, decreases when the messages are larger. In that case, the penalty of the early sleeping problem is higher. Early sleeping problem (Figure 4.5) In this experiment, we show the effectiveness of the measures addressing the early sleeping problem (Section 3.5). We see that the FRTS mechanism increases maximum throughput by approximately 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 more realistic scenario. In this experiment, events occur in the network with a frequency of one per 10 seconds. Events have an average duration of 5 seconds and affect an area of approximately 9 nodes. These nodes then send local unicast messages to their neighbors for the duration of the event. A neighbor that receives one of these messages replies with a probability of 20%. We performed multiple measurements, with different message frequencies during events. This frequency is on the horizontal axis of the graph (Figure 4.6). For T-MAC, we used overhearing avoidance but no FRTS and no full-buffer priority. 25
Nodes-to-sink, msglenth=20 4.5
energy used [avg. mA / node]
4 3.5 3 2.5 2 1.5 1 CSMA S-MAC T-MAC
0.5 0 0
0.05
0.1 0.15 load [msg / node / s]
0.2
0.25
Nodes-to-sink, msglength=100 4.5
energy used [avg. mA / node]
4 3.5 3 2.5 2 1.5 1 CSMA S-MAC T-MAC
0.5 0 0
0.05
0.1 0.15 load [msg / node / s]
0.2
0.25
Figure 4.4: Nodes-to-sink at moderate (20 bytes data) and larger (100 bytes data) message length.
26
T-MAC nodes-to-sink, msglength=20 1.2
energy used [avg. mA / node]
FRTS + prio 1 0.8
FRTS
0.6
prio
0.4
no measures
0.2 0 0
0.05
0.1 load [msg / node / s]
0.15
0.2
Figure 4.5: T-MAC options in a nodes-to-sink pattern.
Event-based unicast, msglength=20 4.5
energy used [avg. mA / node]
4 3.5 3 2.5 2 1.5 1 CSMA S-MAC T-MAC
0.5 0 0
1
2
3 4 5 peak load [msg / node / s]
6
7
8
Figure 4.6: An event-based scenario, where active nodes exchange local unicast messages.
27
Event triggered reporting 4
energy used [avg. mA / node]
3.5 3 2.5 2 1.5 1 0.5 0 CSMA
T-MAC
S-MAC
Figure 4.7: A complete scenario with both periodic reporting and event-based messages. Figure 4.6 shows that T-MAC uses much less energy than either S-MAC or CSMA, especially when the message frequency during events increases. However, the maximum frequency that T-MAC can handle is lower than that of S-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 many edge nodes. Event-based local unicast and node-to-sink reporting (Figure 4.7) This is an experiment with a complete scenario. When no events happen, nodes exchange local messages of 10 bytes with each other every 20 seconds. They also report to a sink node every 100 seconds. When an event happens (once every 10 seconds, like in the previous experiment), nodes in the neighborhood of the event start sending local unicast messages of 30 bytes, with a rate of 4 per second. 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 for at least 715 ms in every second. For the T-MAC protocol, we used overhearing avoidance, but no FRTS and no full-buffer priority. Figure 4.7 clearly shows the disadvantage of a fixed-length active part: to be able to handle a short-lived burst of traffic—even though that happens relatively seldom—the deployer of S-MAC must choose a long active part of the duty cycle. S-MAC therefore wastes much energy at times when no events happen. By adaptively changing the duty cycle, T-MAC can decrease the used energy in this scenario by a factor 5.
28
Chapter 5
Real-world experiments In this chapter, we report our experiences with the actual implementation of the T-MAC protocol. We start by presenting the operating environment. Then we describe the implementation of the T-MAC protocol and the variations between the ‘theoretical’ and the ‘real’ implementations. We end with some power measurements.
5.1
Operating environment
To implement and test the T-MAC protocol on the real EYES nodes, we needed some basic operating system. Since the EYES hardware is new, no such operating system existed yet. We had three choices: 1. wait for the end of a project at the University of Twente—this project had 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 functionality to 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 before we needed it. The TinyOS system is too simple for our testing purposes and porting it would, in our opinion, be more work than writing an operating system that was designed specially for the EYES hardware. We therefore decided to go our own way. Although the core OS has been implemented within a week, functionality has been added when needed. In the end, we had a usable system that may serve as a stable base for future expansion. Features are: • support for both event-based and thread-based (blocking) programming models; • multi-threading: multiple threads can exist; • an event signalling system for communication between event-based parts and thread-based parts, or between multiple threads; 29
• 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, CRC checks, 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) code and buffers (network, serial port), uses approximately 16 KB of code and 416 bytes of RAM of the available 60 KB ROM and 2 KB RAM; the T-MAC protocol implementation itself uses only 42 bytes of state. As a side project to the theoretical work and simulations, the design and implementation of this little operating system was both a learning and pleasing distraction. We learned much about the actual hardware, and some of it could be fed back into the simulation model.
5.2
Implementation issues
We did not implement all features of the T-MAC protocol onto the EYES hardware. To test the effectiveness of the full-buffer-priority and future-RTS schemes, a large-scale experiment is needed, involving a lot of nodes. Since there was no time do such an experiment, implementation of these features was senseless. 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-cluster configurations. During testing, we noted that the nodes’ schedules would drift apart relatively fast. Even though the time-keeping on all nodes is based on ticks of a quartz crystal, 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 node receives a SYNC message that contains almost, but not exactly, its own schedule, the node adjusts its own schedule towards the received schedule. To allow a converging situation, the schedule is only adjusted for 50% of the difference between the two schedules. 30
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 of data messages, the nodes rarely go to sleep. But when no messages are sent, the indication LEDs on the nodes blink peacefully. The radio is then in the receive mode 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 of power usage experiments.1 In these experiments, one node was sending, another receiving. 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. This voltage was measured using specialized equipment, which sent the values to a computer. At the computer, we captured the values. After precise calibration, we could measure the electrical current through the node with a precision of approximately 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 consumption 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 is on. We also see two higher spikes. These are SYNC packet transmissions. In Figure 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 in sleep 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 is clear that this node never sleeps, as it should not. Instead, it toggles between receive (3.75 mA) and transmit (18 mA). Figure 5.4 shows a closeup of a node transmitting 3 messages during a single frame. The traces show that the current during transmission peaks between 18 and 20 mA—while it should be around 10 mA (max 12 mA) according to the radio specifications. The difference may be due to a short startup spike, or to the radio not behaving within the specifications. The traces were too coarsegrained 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 be wrong—it would be biased in favor of protocols that allow more control packets and retransmissions to save radio listening time. The current while receiving averages between 3.75 and 4 mA, which is according to the specifications. Table 5.1 shows the average power usage during each experiment. We can see that transmitting nodes use significantly more energy than receiving nodes. This is logical, since transmitting with our radio takes more power than 1 In this section, we use the term power instead of energy to emphasize that we are talking about 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, when we should strictly say electrical current. This is permitted, since the voltage is constant (joules are consumed at a rate of (I × 3V ) per second). To re-cap: dE/dt = P = V × I.
31
20 18 16
current [mA]
14 12 10 8 6 4 2 0 0
2
4
6
8
10
8
10
time [s]
Figure 5.1: Power usage trace, idle.
20 18 16
current [mA]
14 12 10 8 6 4 2 0 0
2
4
6 time [s]
Figure 5.2: Power usage trace, receiving node, 1 message / second.
32
20 18 16
current [mA]
14 12 10 8 6 4 2 0 0
2
4
6
8
10
time [s]
Figure 5.3: Power usage trace, transmitting node, full speed.
25
RTS
DATA
RTS
DATA
RTS
DATA
current [mA]
20
15
10
5
TA
CONTEND CTS
CTS ACK CONTEND
CTS ACK CONTEND
ACK
0 6.18
6.2
6.22 time [s]
6.24
6.26
Figure 5.4: Power usage trace, transmitting node, 10 messages / second.
33
6.28
msg / s 0 1 10 max
transmit mA 0.138 0.400 1.516 9.590
receive mA 0.138 0.246 0.890 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 (which would be between 3.75 and 4 mA). This is well above the theoretical limit (TA/Tf rame = 15 ms/610 ms = 2.5%). However, the theoretical limit only takes the radio energy usage into account, not the CPU, EEPROM, RS232 voltage converter and other components. We think that 96% overall energy savings is a very good result.
34
Chapter 6
Conclusions and future work We have presented T-MAC, a MAC protocol for wireless sensor networks, which saves energy by turning off the radio as much as possible. The moment to turn off 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 problem in an environment with variable network traffic load. Implementation of the idea with the T-MAC protocol has shown the advantages, both in simulation and on real 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 the time, saving as much as 96% of the energy compared to a traditional protocol. The T-MAC protocol can easily be implemented. The final implementation of the protocol itself requires no more than 42 bytes of state. The time-out scheme, as implemented by the T-MAC protocol, uses significantly less 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 advantage depends mainly on the amount of variation in the message rate. Even in a homogeneous, non-varying environment the T-MAC protocol can be advantageous, since it requires no tuning to the specific message rate, while the S-MAC protocol must be tuned precisely for optimal energy savings. Deployment of the T-MAC protocol can therefore be faster. Simulations of the T-MAC protocol have shown a new problem: the early sleeping problem, which decreases throughput dramatically in an asymmetric communication pattern. We have presented two solutions that increase the throughput by more than 100%, but it is still less than optimal. This is a trade-off to the adaptiveness of the protocol. However, we do not expect such very high message rates in wireless sensor networks. We have encountered the early sleeping problem only in a perfect, simulated world. It may well be the case that the problem does not exist when nodes are spread more randomly, or have more neighbors. Or maybe the problem becomes much worse, making the T-MAC protocol unusable. Future work is needed to 35
determine the seriousness of the early sleeping problem, both in a more realistic simulation setting and in large-scale experiments with real hardware. These experiments should also test the effectiveness of the proposed solutions. We have only experimented with a static, non-mobile network. We expect problems when applying virtual clustering to groups of mobile nodes. The virtual clustering technique, proposed in the S-MAC protocol and re-used in the TMAC protocol, has not been researched thoroughly. Since the T-MAC protocol leans heavily on some kind of synchronization, the clustering is important. More research should be done on virtual clustering, and on multi-hop synchronization in general, both in static and in mobile networks.
36
Bibliography [1] V. Bharghavan, A. Demers, S. Shenker, and L. Zhang. MACAW: a media access protocol for wireless LAN’s. In Proceedings of the conference on Communications Architectures, Protocols and Applications, pages 212–225, London, 1994. [2] Deborah Estrin, Ramesh Govindan, John S. Heidemann, and Satish Kumar. Next century challenges: Scalable coordination in sensor networks. In Fifth Annual ACM/IEEE International Conference on Mobile Computing and Networks (MobiCOM ’99), pages 263–270, Seattle, Washington, USA, August 1999. [3] P.J.M. Havinga and G.J.M. Smit. Energy-efficient TDMA medium access control protocol scheduling. In Proceedings Asian International Mobile Computing Conference (AMOC 2000), pages 1–9, November 2000. [4] Phil Karn. MACA - a new channel access method for packet radio. In Proceedings of the 9th ARRL Computing Networking Conference, 1990. [5] LAN MAN Standards Committee of the IEEE Computer Society. IEEE Std 802.11-1999, Wireless LAN Medium Access Control (MAC) and Physical Laer (PHY) specifications. IEEE, 1999. [6] RFM. TR1001 868.35 MHz Hybrid Tranceiver. [7] RFM. ASH Transceiver Designer’s Guide, October 2002. [8] S. Singh and C.S. Raghavendra. PAMAS: Power aware multi-access protocol with signalling for ad hoc networks. ACM SIGCOMM Computer Communication Review, 28(3):5–26, July 1998. [9] M. Stemm and R. H. Katz. Measuring and reducing energy consumption of network interfaces in hand-held devices. IEICE Transactions on Communications, E80-B(8):1125–1131, 1997. [10] Texas Instruments. MSP430x1xx Family User’s Guide. SLAU049B. [11] Y. Tseng, C. Hsu, and T. Hsieh. Power-saving protocols for IEEE 802.11based multi-hop ad hoc networks. In Twenty-First Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM), volume 1, pages 200–209, June 2002. 37
[12] A. Varga. The OMNeT++ discrete event simulation system. In European Simulation Multiconference (ESM’2001), Prague, Czech Republic, June 2001. [13] W. Ye, J. Heidemann, and D. Estrin. An energy-efficient MAC protocol for wireless sensor networks. In Twenty-First Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM), volume 3, pages 1567–1576, June 2002. [14] http://eyes.eu.org [15] http://webs.cs.berkeley.edu/tos/
38
