The Challenges of Wireless Sensor Networks

Worked: a node that never sleeps. Suppose the node runs on a battery pack rated 2,500 mAh (an assumption for the exercise; the chapter [How Long a Node Lasts: The Energy Budget Worked Out] uses real battery figures). A radio left listening draws 18.8 mA, so the battery lasts 2,500 / 18.8, about 133 hours, which is about five and a half days. A network designed to last a season is dead in a week. Keeping the radio off for most of the time is not an optimisation; it is the only way the network can exist.

2. Limited processing power and memory

The MSP430F1611 has 10 KB of RAM and 48 KB of flash for program code. A phone has millions of times more. A protocol that keeps a large table, a long queue or a big buffer simply does not fit, and an operating system designed for a desktop is out of the question. The first TinyOS, by comparison, fitted in 178 bytes of memory. Everything that runs on a node must be small and simple, which is why [Why a Sensor Node Needs an Operating System] exists.

3. Unreliable, time-varying wireless links

A radio link is not a wire. Its quality changes with the weather, with people and vehicles moving about, and with other radios: the 2.4 GHz band that many sensor nodes use is shared with Wi-Fi, Bluetooth and microwave ovens. Links can be asymmetric (A hears B but B does not hear A), and between the range where every packet arrives and the range where none does lies a wide band where some arrive and some do not, which the chapter [TOSSIM: Simulating Motes, Radio Gain and Packet Loss] explains. A protocol that assumes a link either works or does not will fail in the field.

4. Unattended operation and self-configuration

Nobody stands beside each node to give it an address, tell it who its neighbours are or set up its routes. After deployment the nodes must discover their neighbours, build routes, and repair them when something changes, all by themselves. A network of a thousand nodes cannot be configured by hand even if someone were there.

5. Large scale and high density

The survey expects deployments of hundreds or thousands of nodes, sometimes more, with densities as high as 20 nodes in a cubic metre. At that scale a node cannot know the whole network. Every algorithm must be local: a node decides from what its neighbours tell it, never from a global picture. And with so many nodes in one radio range, their transmissions collide unless the MAC protocol keeps them apart.

6. A dynamic topology

The survey divides the topology's life into three phases: deployment, post-deployment (when the topology changes because nodes move, links are jammed or blocked, batteries run down, or nodes malfunction) and redeployment of additional nodes. On top of that, nodes that sleep to save energy are, from their neighbours' point of view, temporarily absent. So the set of working links changes all the time, and routes must adapt.

7. Application-specific quality of service

On the Internet, quality of service means throughput and delay. A sensor network's user wants something else: that every fire is detected, that the location of a vehicle is estimated within five metres, that the average temperature is right to half a degree. These are measures of the information, not of the bits, and they differ from one application to another. Designing for them is the subject of [Optimization Goals: Quality of Service, Energy Efficiency and Lifetime].

8. Being data-centric, and processing in the network

The user asks about the phenomenon, not about node number 145, and nodes may not even have globally unique identities. The network has to route, name and store data by what it is and where it came from, and combine it on the way. That is a different way of building a network from the one students learn first, and it is a challenge because the familiar tools (IP addresses, end-to-end connections) do not apply.

9. Security

Nodes lie in the open, where an attacker can pick one up, read its memory and reprogram it. The radio is a broadcast medium that anyone can hear and anyone can transmit on. And the node cannot afford the cryptography a server uses. Keeping data secret and authentic, and keeping routing honest, is hard, which is why the book gives it four chapters starting from [Security in Ad Hoc and Sensor Networks: Goals, Constraints and Attacks].

10. Time synchronisation and localisation

A reading is useless without when and where. Each node has its own clock, which drifts, and giving every node a satellite receiver to learn its position costs too much money and energy. So nodes must agree on the time and work out their positions among themselves, which is [Time Synchronisation and Localisation].

11. Programming, deployment and maintenance

A bug found after deployment must be fixed on a thousand nodes scattered across a forest, without collecting them. The network has to be reprogrammable over its own radio, tested before it goes out, and monitored while it runs. Tools for programming a whole network, rather than one node, are part of the answer, and [WSN Middleware: Why It Is Needed, and Its Architecture] describes them.

12. Cost

Because a network needs many nodes, each must be cheap. The survey, writing in 2002, went as far as to say a node should cost "much less than US$1" for a sensor network to be feasible, a target far below what real nodes cost then or now. Cheap hardware means small batteries, simple radios and little memory, which feeds straight back into challenges 1 to 3.

The same challenges, as MU's second text book organises them

Karl and Willig, the second text book on MU's list, split the challenges into two lists, and an answer that uses their headings is well organised.

The characteristic requirements, the properties most applications demand:

1. Type of service. A WSN is not there to move bits but to give meaningful information about a task; they quote a Berkeley engineer's line, "People want answers, not numbers". Interactions are scoped to regions and time intervals.
2. Quality of service. Bounded delay and minimum bandwidth often do not matter; what matters is the amount and quality of information extracted, such as reliable detection of events or the accuracy of a temperature map. They add that the packet delivery ratio "is an insufficient metric".
3. Fault tolerance, achieved by redundant deployment: more nodes than would be needed if every node worked.
4. Lifetime, a "very important figure of merit", whose precise definition depends on the application ([Optimization Goals: Quality of Service, Energy Efficiency and Lifetime] gives the definitions).
5. Scalability to large numbers of nodes.
6. A wide range of densities, varying between applications and within one network over time and space.
7. Programmability: nodes must be reprogrammable during operation as tasks change.
8. Maintainability: the network must monitor its own health and adapt, for example by giving lower quality when energy runs short.

The required mechanisms, the techniques that meet those requirements:

1. Multi-hop wireless communication, because direct communication over long distances needs prohibitively high power.
2. Energy-efficient operation, including avoiding "hotspots" where energy consumption concentrates.
3. Auto-configuration, including nodes working out their own positions ("self-location"), tolerating failed nodes and integrating new ones.
4. Collaboration and in-network processing, such as combining readings as they travel to find the highest or average temperature.
5. Data-centric operation, asking for values rather than for particular nodes.
6. Locality: each node keeps state only about its direct neighbours, so the network can scale.
7. Exploiting trade-offs, such as energy against accuracy, or the lifetime of the whole network against the lifetime of individual nodes.

The twelve challenges above and these two lists describe the same ground. The twelve are organised by problem; Karl and Willig organise by what the application needs and what the network must do about it.

How the challenges pull against each other

The challenges are not independent, and the hard part of design is that solving one makes another worse.

• Energy against delay. Sleeping saves energy, but a packet that arrives for a sleeping node must wait. Every duty-cycling MAC protocol trades one for the other, and [S-MAC: Latency, Adaptive Listening and the Energy Saved] measures the trade.
• Energy against reliability. Acknowledging and retransmitting packets makes delivery reliable, and costs energy each time.
• Cost against lifetime. A bigger battery lasts longer and costs more.
• Density against collisions. More nodes give better coverage and more redundancy, and more radios contend for the same channel.
• Security against energy. Every byte of authentication code added to a packet is transmitted, and transmission is the most expensive thing a node does.

The challenges, as numbers

Every challenge listed above is a number underneath, and the numbers are worth seeing together, because they are not independent: each one is bought with another.

# Each challenge, given the one number that makes it a challenge.
import math

V, CAPACITY_MAH = 3.0, 2500.0          # two AA alkaline cells, a round figure
JOULES = CAPACITY_MAH / 1000 * 3600 * V
I_RX, I_TX, I_SLEEP = 18.8e-3, 17.4e-3, 20e-6
RATE = 250e3
DAY = 24 * 3600.0

print("Every challenge in this chapter is a number. Here they are.")
print()
print("ENERGY. Two AA cells hold about %.0f joules." % JOULES)
for name, cur in (("listening, radio always on", I_RX),
                  ("listening one second in ten", I_RX * 0.1 + I_SLEEP * 0.9),
                  ("listening one second in a hundred", I_RX * 0.01 + I_SLEEP * 0.99),
                  ("listening one second in a thousand", I_RX * 0.001 + I_SLEEP * 0.999)):
    life = JOULES / (cur * V)
    print("  %-36s %8.1f days" % (name, life / DAY))
print("  a node that is simply left switched on lasts under a week; the same node at a")
print("  thousandth of a duty cycle runs for over seven years, which is about as long as")
print("  the cell will sit on a shelf anyway. The challenge")
print("  is not the battery. It is the radio being on.")

print()
print("BANDWIDTH. One channel of %.0f kbit/s, shared." % (RATE / 1000))
for n in (10, 100, 1000):
    share = RATE / n
    print("  %4d nodes sharing it: %8.0f bit/s each before any collision at all"
          % (n, share))
print("  and that is the ideal. Contention takes a large part of it back, which is why")
print("  the MAC chapters spend so long on collisions.")

print()
print("SCALE. A flood reaches everyone by making everyone shout.")
for n in (10, 100, 1000):
    print("  %4d nodes: one flood is %4d transmissions, and a query answered by all of"
          % (n, n))
    print("       them is another %4d coming back" % n)
print("  the traffic grows with the number of nodes, and so does the chance two of them")
print("  speak at once. Nothing about a protocol that works for ten is evidence it works")
print("  for a thousand.")

print()
print("LATENCY. Sleeping costs time as surely as listening costs energy.")
for duty, frame_ms in ((0.1, 100), (0.01, 1000), (0.001, 10000)):
    wait = frame_ms / 2.0
    for h in (5, 10):
        print("  at %5.1f%% duty with a %4d ms cycle, a %2d hop path waits about %6.0f ms"
              % (duty * 100, frame_ms, h, h * wait))
print("  a network that sleeps to survive is a network that answers slowly, and the two")
print("  cannot both be optimised. That is the trade every MAC in this book is making.")

print()
print("COST AND UNATTENDED OPERATION.")
for per_node in (300, 1000, 3000):
    for n in (100, 1000):
        print("  %4d nodes at Rs %4d each: Rs %9d of hardware" % (n, per_node, n * per_node))
print("  and one visit by one person to replace one battery, at a day's wage and a day's")
print("  travel, can cost more than the node. That is why the design target is a node")
print("  that is never visited, and why every other challenge reduces to energy.")

Distinctions: each challenge, and where the book answers it

What it does not mean

Energy being limited does not mean the answer is a bigger battery. A bigger battery makes the node bigger and dearer and only postpones the problem by a constant factor. The real answer is to change what the node does, above all to keep its radio off.

The processor is not the energy problem. It is natural to assume that computing is what uses the power. On these chips the radio listening uses about 57 times as much as the processor running.

An unreliable link is not a broken radio. Links in the band between perfect and dead are normal in every real deployment, and protocols must be designed for them, not tested only where every packet arrives.

Challenges are not the same as design factors, but they overlap. The survey's design factors (fault tolerance, scalability, cost, environment, topology, hardware, medium and power) are the properties a designer must take into account; the challenges are the problems those factors create. Both are asked, and [The Operating Environment and the Design Factors] teaches the factors with their formulas.

Quick revision

• Twelve challenges: energy; processing and memory; unreliable links; unattended self-configuration; scale and density; dynamic topology; application QoS; data-centric operation; security; time and position; programming and maintenance; cost.
• CC2420: receive 18.8 mA, transmit 17.4 mA, idle 0.426 mA, power down 0.02 mA. MSP430F1611: active 0.33 mA at 1 MHz, standby 0.0011 mA; 10 KB RAM, 48 KB flash.
• Listening costs as much as sending; the radio costs about 57 times the processor; sleeping is almost free.
• A 2,500 mAh battery (assumed) with the radio always listening: 2,500 / 18.8, about 133 hours, five and a half days.
• Densities up to 20 nodes per cubic metre; hundreds to thousands of nodes; the first TinyOS in 178 bytes.
• Karl and Willig: requirements type of service, QoS, fault tolerance, lifetime, scalability, range of densities, programmability, maintainability; mechanisms multi-hop, energy efficiency, auto-configuration, collaboration and in-network processing, data-centric, locality, exploiting trade-offs.
• The challenges pull against each other: energy against delay, reliability, security; density against collisions; cost against lifetime.

Test yourself

1. List eight challenges of wireless sensor networks. Any eight of: limited, irreplaceable energy; limited processing and memory; unreliable, time-varying links; unattended operation and self-configuration; large scale and high density; dynamic topology; application-specific QoS; data-centric operation; security; time synchronisation and localisation; programming and maintenance; cost.

2. Using the CC2420 and MSP430F1611 figures, explain why the radio is the main energy problem. The radio draws 18.8 mA receiving and 17.4 mA transmitting, while the processor draws 0.33 mA active at 1 MHz. Listening therefore costs about 57 times as much as computing, so a node should compute to reduce what it sends and should keep its radio off whenever it can.

3. What is idle listening, and why does it matter? Keeping the receiver on while waiting for a packet that may never come. On the CC2420 it draws the full 18.8 mA of receiving, as much as transmitting, so a node that idles with its radio on wastes energy as fast as one that is talking.

4. A node's radio listens continuously on a 2,500 mAh battery. Roughly how long does it last? 2,500 / 18.8, about 133 hours, or about five and a half days.

5. Why must sensor network algorithms be local? Because with hundreds or thousands of nodes, densities up to 20 a cubic metre and a constantly changing topology, no node can know the whole network. Each node must decide from what its neighbours tell it.

6. Give two pairs of challenges that pull against each other. Energy against delay (sleeping saves energy but delays packets for sleeping nodes), and density against collisions (more nodes improve coverage but contend for the channel). Others: energy against reliability, security against energy, cost against lifetime.