The platforms enabling wireless sensor networks

THE PLATFORMSENABLING WIRELESSSENSOR NETWORKS

By Jason Hill, Mike Horton, Ralph Kling, and Lakshman Krishnamurthy

All emphasize low-cost components operating on shoestring power budgets for years at a time in potentially hostile

environments without hope of human intervention.

COMMUNICATIONS OF THE ACM June 2004/Vol. 47, No. 6 41

Wireless sensor networkscombine processing, sens-ing, and communicationsinto tiny embeddeddevices. Peer-to-peer com-munication protocols thencombine the individualdevices into an intercon-

nected mesh network where data is seamlesslyrouted among all the nodes. These networks requireno external infrastructure and can scale to hundredsor even thousands of nodes.

Here, we explore the standard sensor network plat-forms where devices range from millimeter-size cus-tom silicon to PDA-size integrated units. Critical tothe operation of any sensor network device is the abil-ity to satisfy harsh always-on power requirements.Unlike cell phones and wireless laptops, periodicrecharging is not possible for most wireless sensor net-works. In many cases, devices are placed in the fieldfor years at a time without maintenance or humanintervention of any kind.

In sensor networking, special-purpose sensor nodesare purposely designed to sacrifice flexibility in orderto be as small and inexpensive as possible. Genericsensor nodes provide a rich expansion interface for

making flexible connections with an array of simplesensors. High-bandwidth sensor nodes contain thebuilt-in processing and communication capabilitiesneeded to deal with complex sensor streams, includ-ing video and voice processing. Gateway nodes pro-vide a critical link between the sensor network andtraditional networking infrastructures, including Eth-ernet, the 802.11 communication standard, andwide-area networks.

Traditional network abstractions are generally notsuitable for wireless sensor networks. Unlike tradi-tional operating systems, operating systems for wire-less sensor networks must tightly integrate wirelessconnectivity. For example, in TinyOS [5], a special-ized component model exploits advanced compilertechnology to simultaneously provide efficiency andreliability [1, 5]. These same concepts are now beingincorporated into more traditional operating systemsin gateway-class and high-bandwidth nodes [2].

Here, we outline the four main platform classesthat have emerged in recent years in wireless sensornetworks; devices from multiple platform classesoften work together in real-world application deploy-ments. We also review the architectural similarities ofsensor network devices, exploring the core differencesamong classes, and consider the recent progression of

42 June 2004/Vol. 47, No. 6 COMMUNICATIONS OF THE ACM

sensor-network hardware, extrapolating future capa-bilities in future devices.

Platform ClassesInitial deployment experience has shown that sensornetwork systems require a hierarchy of nodes start-ing at low-level sensors and continuing up throughhigh-level data aggregation, analysis, and storagenodes (see Figure 1). This tiered architecture is com-mon in virtually all sensor networks and is best illus-

trated by example.Consider a sensor networkfor an advanced security sys-tem in which a majority of

the sensors cover window breakage, contact closure,and motion detection. The quantity and range oflocations for these simple sensors require that they bebattery powered. They are complemented by a hand-ful of more advanced sensors, including cameras andacoustic and chemical detectors, placed in key loca-tions. Both simple and complex sensor data is routedover a mesh network into a building-monitoring-and-control facility that provides a continuious monitor-ing capability.

The sensors placed on windows and doors forintrusion detection are examples of generic sensingdevices. Their function is simple and specific andrequires long-term battery operation. Moreover, theiron-board processing and communication rates areminimal. In contrast, acoustic, video, and chemicalsensors are examples of high-bandwidth nodes requir-ing more computational resources and communica-tion. They may, in some cases, require battery power

but often need to be plugged into the public powersystem for long-term operation.

In addition to traditional security applications,wireless sensor networks are being designed to trackmobile assets, as well as personnel, through attachedtiny, low-cost security tags (mini-motes). These spe-cial-purpose sensor nodes are synonymous withSmart Dust [8], or cubic-millimeter-scale devices sup-ported by extremely limited energy resources. Theycould trigger an alarm when an asset leaves a facility

without authorization. Moreover,they must be highly integrated andvery inexpensive.

In security systems, the meshnetwork of sensors is likely to haveone or more end points containinga database or other aggregationsoftware designed to process andstore individual sensor readings.These head, or gateway, nodesprovide an interface into manyexisting types of networks.

Table 1 outlines typical operat-ing characteristics of the fourclasses of nodes—specialized sens-ing platform, generic sensing plat-form, high-bandwidth sensing,and gateway—implemented withstate-of-the-art technology. TheSpec node the author Hilldesigned at the University of Cali-

fornia, Berkeley, is representative of the special-pur-pose sensor class. It is a single-chip node designedspecifically for ultra-low-cost production and low-power operation. Requiring just 2.5 mm � 2.5 mmof silicon, it includes data RAM, processing, andcommunication capabilities. In order to reduce sizeand complexity, the Spec node was built so it wouldinterface only with simple sensors and communicateonly over short distances. The prototype versions(produced February 2003) contained only a transmit-ter (without a receiver); future versions will contain afull transceiver. The Spec node is an ideal asset tag;combined with a tiny battery, it is capable of periodi-cally reporting its presence for years to come.

The Berkeley Motes are a notable example of ageneral-sensing-class device, used today by more than100 research organizations. The Mica2 is the mostrecently developed commercially available version,constructed from off-the-shelf components to pro-vide the greatest possible flexibility (see Figure 2). Itincludes a large interface connector allowing itsattachment to an array of sensors. By providing alarge number of I/O pins and expansion options, the

Web interfaces,databases

Cameras,microphones

Dozens of high-bandwidth sensors

Door, window,motion sensors

Asset tags

A few gateway nodes

The Internet

Hundreds of genericsensor nodes

Thousands ofspecial-purposesensors

Figure 1. Hierarchical deployment of a wireless sensor network. Each platformclass handles different typesof sensing.

Mica2 is a perfect sensor node option for any applica-tion where size and cost are not absolutely critical. Itis, for example, easily connected to motion detectorsand door-and-window sensors as the foundation of abuilding security system. Moreover, the Mica2 iscapable of receiving messages from Spec nodesattached to high-value assets, including personal com-puters and laptops, at risk of being stolen. The mem-ory and processing power available on the Mica2 node

easily handles the computa-tion required to keep trackof several dozen Spec-basedasset tags.

While the Mica2 node is easily interfaced by hard-ware engineers to an array of sensors, it cannot handlethe high bandwidth of data coming from complexsensors. When attemptingto process video or high-bandwidth audio, theMica2 node falls short. TheiMote, developed by IntelResearch (first produced inMay 2003), is designed tobe a high-bandwidth sensorplatform, including signifi-cantly more on-chip RAMand processing power, aswell as a Bluetooth-basedradio capable of communi-cation rates in excess of500Kbps.

The Stargate platformdeveloped by Intel and soldby Crossbow Technology is representative of gateway-class devices and includes a 400MHz X-scale architec-ture-based processor (also developed by Intel) withseveral megabytes of RAM and up to gigabytes of per-

sistent storage. It is capable of interfacing directly toMica2- and iMote-based devices and bridging thedata from low-power mesh networks to traditionalnetworks, including 802.11, Ethernet, and wide-areavarieties. Moreover, the processing and memory pro-visions on the Stargate node allow it to act as a Webfront-end to sensor networks where users access itsdata via a Web browser.

The operating system running on a particular plat-form must be matched to the plat-form’s underlying hardwarecapabilities. For special-purposeand generic-sensor-class devices, aspecial operating system calledTinyOS (developed at the Univer-sity of California, Berkeley) isdesigned to run on platforms withlimited CPU power and memoryspace. Unlike many embeddedoperating systems, it provides tightintegration between wireless con-nectivity and networking func-tions. However, as platformcapabilities improve with, forexample, the Stargate platform,more advanced operating system

support is required to meet the demands of morecomplex applications. Multiprocessing, preemptivetask switching, and even virtual memory supportbecome desirable when managing multiple systemfunctions. The Stargate node runs an embedded ver-sion of the Linux operating system. In addition toproviding a range of system capabilities, Linux pro-

vides a suite of device dri-vers for enabling gatewaynodes to bridge to legacynetworks. Drivers forEthernet cards and802.11 wireless network-ing cards are essential forallowing the gatewaynodes to bridge to arange of wide-area net-working systems.

Architectural DifferencesThe overall architectures of the four sensor-networkplatform classes are remarkably similar despite sig-nificant differences in device capabilities. The archi-tectural similarity follows from the requirement thatthey seamlessly integrate wireless networking. Net-work support must be transparent and self-configur-ing to allow sensor networks to scale in size andcomplexity. In contrast, their core differences come


Node Type

Sample“Name”and Size

Typical ApplicationSensors

RadioBandwidth(Kbps)

MIPS

Flash

RAM

TypicalActiveEnergy(mW)

TypicalSleepEnergy(uW)

TypicalDutyCycle(%)

Specializedsensingplatform

Genericsensingplatform

High-bandwidthsensing

Gateway

Spec

mm3

Mote

1-10cm3

Imote

1-10cm3

Stargate

>10cm3

Specialized low-bandwidth sensoror advanced RF tag

General-purposesensing andcommunications relay

High-bandwidthsensing (video,acoustic, andvibration)

High-bandwidthsensing andcommunicationsaggregationGateway node

<50Kbps

<100Kbps

~500Kbps

>500Kbs–10 Mbps

< 5

< 0.1Mb

< 4Kb

< 10

< 0.5Mb

< 10Kb

< 50

< 10Mb

< 128Kb

< 100

< 32Mb

< 512Kb

1.8V*10–15mA

3V*10–15mA

3V*60mA

3V*200mA

1.8V *1uA

3V *10uA

3V *100uA

3V *10mA

0.1–0.5%

1–2%

5–10%

>50%

Table 1. Typical operatingcharacteristics of the fourclasses of sensor-networknodes.

External Power Connector

Power Switch

(Radio on back)

AA Batteries

External RFConnector

Antenna

Expansion Connector

CPU

Figure 2. The Mica2 node isthe most popular sensor-net-work research platform. The

large expansion connectorallows it to be connected to a

wide range of sensors.

from their developers’ desire to optimize the powerconsumption of each platform for a certain class ofapplication. Some of the fundamental decisionsthat must be made by application engineers includethe amount of on-board memory, whether to includeflash memory, the amount of CPU processing power,and the type and bandwidth of the wireless link.Since most implementationsemploy off-the-shelf compo-nents, some of these decisions aredictated by the availability ofsuitable parts. In the end, costand power consumption aremajor factors influencing thefinal design of any given sensornode.

Amajor differencebetween sensor-network nodesand more tradi-tional comput-ing platforms,including PCs,PDAs, and even

embedded devices, is the extremeemphasis in sensor networks onpower management. A largenumber of applications requirebattery-powered operation forextended periods of time. Inorder to manage power effi-ciently, each subsystem of theplatform is powered individually.For example, a radio should haveto be turned on only duringactive communication, and itshould be possible to shut downthe CPU between processingrequests. Similarly, it should bepossible to power down the sen-sor and I/O subsystems individu-ally when not in use. Theoperating system, TinyOS inmany cases, controls the activity and power state ofthe various subsystems. The exact timing of thepower-down cycles is determined by a number of fac-tors, including application requirements and the par-ticular hardware being used. In TinyOS, powermanagement pervades every aspect of the system,and all components are designed to save power whennot active.

To facilitate proper power management, sensor-network platforms give applications direct, fine-grain

control over the underlying hardware. Traditionallayered abstractions for both network [2] and sensorstacks lead to inefficiencies in power usage. Recentresearch suggests a common approach to solving thischallenge across the range of platforms [2, 5] by wayof three additional architectural components:

• A general-purpose component framework thateliminates layering;

• Hardware functions that are exposed to applica-tions and middleware; and

• Virtualization, or a unifying layer of abstraction,and interpreted scripts, or a simplified program-ming process, for writing sensor network applications.

On mote-class devices (such as Spec and Mica2),TinyOS provides low-level hardware control througha built-in component model that eliminates layering.The software abstractions in TinyOS are designed toallow application-level components direct access tohardware as needed. While this capability is alsofound in other embedded operating systems, it is gen-erally not present in more traditional operating sys-tems, including Linux.

Using Linux on gateway-class nodes (such as Star-gate) requires additional support for precise hardwarecontrol, so it was added by developers. On Stargate,processor registers and general-purpose I/O lines aremade available to applications via special-purpose dri-vers. In turn, sensor-network development environ-ments (such as Emstar [2]) employ these drivers togive applications control over the timing and state ofthe hardware peripherals they need (see Figure 3).

The TinyOS and embedded-Linux developmentefforts have each embraced virtualization of process-ing and communication resources to simplify thesensor-network development process. One trade-offin providing precise hardware control to application-


Main

Photo

StdControl ADC

SurgeC

StdControl

StdControl

ADC Timer SendMsg LEDs

SurgeM

TimerC

TinyOS Components for Surge Application

Emstar Component Layout

StdControl

LEDsC

LEDsTimer

Multihop

StdControl SendMsg

Application code

Neighbors

Routing

Link

EmRunRuntime

componentmanager

Figure 3. Emstar applications consist of

active processes and Linux device

drivers using message passing to communicate;the component model

allows nonlayeredinteractions among

components. The system includes a

runtime componentmanager called

EmRun that uses a configuration script

to wire up componentsand provide

logging services andruntime component

performance monitoring. Similarly,

the TinyOS componentmodel gives

applications directaccess to low-level

components (such asLEDs and timers) and

complex operations(such as multihop

routing).

level software is that hardware-specific modules sometimes ren-der sensor-network softwarenonportable. TinyOS and Emstarboth feature hardware abstractionsthat attempt to maintain portabil-ity without sacrificing precise con-trol. Each provides the option ofusing high-level interpreters [2, 6,7] to simplify application develop-ment. However, researchers muststill determine how to ensure ahigh degree of efficiency, alongwith resource virtualization.

Platform Road MapThe recent research and develop-ment of first-generation wirelesssensor network platforms is nowfeeding back on itself to help sys-tems engineers define a new gen-eration of hardware better able tomeet network demands. Table 2outlines the sensor network hard-ware platforms available today.

Hardware progression. Analyzingthe progression of sensor-networkhardware must account for theinfluence of Moore’s Law on thedesign and development of thenetworks. For all platform classesexcept special-purpose sensornodes, Moore’s Law promises anincrease in performance for a givenpower budget. As shown in Table2, the Mica2 node has roughlyeight times the memory and com-munication bandwidth as its pre-decessor, the Rene node, developed in 1999, despiteinvolving the same power and cost. The gateway andhigh-bandwidth devices have achieved similar perfor-mance jumps without significantly changing theirpower or cost requirements. In contrast, the special-purpose sensor nodes (such as Spec) use advancesderived from Moore’s Law to reduce their power con-sumption and cost requirements while maintainingthe same performance level.

Part of the performance increase in the generic-sen-sor-node class is due to new CMOS radios specificallydesigned for low data rates and low power consump-tion. In addition to improving raw radio performancemetrics, the communication interfaces provided bylow-power radio now include specialized hardwaresupport to help reduce the peak load placed on the

CPU. Low-power controllers can burst data out overthe RF channel at rates several times faster than withthe previous generation of radios. Moreover, earlyhardware designs used the microcontroller to dutycycle the radio and check for channel activity [3].Next-generation radios to be released this year willhave built-in state machines that perform this opera-tion automatically.

Software and interface standards. Engineers andresearchers in the field of low-power wireless technol-ogy are pursuing a protocol-standardization effortaimed at allowing future devices to interoperate withone another. The 802.15.4 standard provides a speci-fication of the RF channel and signaling protocol tobe used. Built atop 802.15.4 is the Zigbee protocol, aspecification of the application-level communicationprotocol between devices. To put Zigbee and802.15.4 in perspective relative to the platforms we’vediscussed here, 802.15.4 determines which radiohardware to use, and Zigbee determines the content


Node CPU Power Memory Radio Remarks

Spec 2003

Rene 1999

Mica-2 2001

Telos 2004

Mica-Z 2004

BT Node

2001

Imote 1.0

2003

Stargate

2003

InrysncCerfcube 2003

PC104nodes

4–8MhzCustom 8-bit

ATMEL8535

ATMEGA128

MotorolaHCS08

ATMEGA128

ATMELMega 128L7.328Mhz

ARM7TDMI 12-48MHz

IntelPXA255

IntelPXA255

X86processor

3mWpeak 3uW idle

.036mWsleep60mWactive.036mWsleep

60mWactive

.001mWsleep

32mWactive

50MWidle

285MWactive

1mWidle120mWactive

3K RAM

512B RAM8K Flash

4K RAM128K Flash

4K RAM

4K RAM128K Flash

128KBFlash4KBEEPROM

4KB SRAM

64KB SRAM512KB Flash

32KB Flash

64KNSRM

32KB Flash

64KB SRAM

32KB Flash64KB SRAM

50–100Kbps

10Kbps

76Kbps

250Kbps

250Kbps

Bluetooth

Bluetooth 1.1

I/O and Sensors

I/O Pads on chip,ADC

Large expansionconnector


USB and Ethernet


8-channel 10-bitA/D, 2 UARTS

Expandableconnectors

UART, USB,GPIO, 12C, SPI

2 PCMICA/CF,com ports,Ethernet, USB

Single CF card,general-purpose I/O

PCI Bus

Full custom silicon,traded RF range andaccuracy for low-power operation.

Primary TinyOSdevelopment platform.

Primary TinyOSdevelopment platform.

Supports IEEE 802.15.4standard. Allows higher-layer Zigbee stardard.

1.8V operation

Supports IEEE 802.15.4standard. Allows higher-layer Zigbee stardard.

Easy connectivity withcell phones.

Supports TinyOS.Multihop usingmultiple radios/nodes.

Multihop usingscatternets, easyconnections to PDAs,phones,TinyOS 1.0, 1.1.

Flexible I/O and smallform factor powermanagement.

Small form factor,robust industrialsupport, Linux andWindows CE support.

Embedded Linux orWindows support.

Special-purpose Sensor Nodes

Generic Sensor Nodes

High-bandwidth Sensor Nodes

Gateway Nodes

Serial connection

tosensor

network

Table 2. Current sensor network

platforms organized by device class.

of messages transmitted by each networked node. Fol-lowing the availability of the first 802.15.4 radios inearly 2004, researchers have sought to developTinyOS drivers. When these drivers are completedand released, existing sensor-network applications willbe able to take advantage of the new capabilities of the802.15.4 chips.

Even as the standardization process advances, it isnot clear whether a comprehensive set of standardprotocols will ever be available to meet all applicationrequirements. Unlike traditional Internet applica-tions—nearly all of which use TCP/IP—sensor-net-work applications demand protocols that areoptimized for their unique communication patterns.Additionally, the for-members-only nature of Zigbeestandards and other proprietary solutions imposeadditional hurdles on any widespread sensor-networkstandard-setting process and adoption. In this envi-ronment, TinyOS’s ability to allow application devel-opers to assemble custom protocols from individualnetworking building blocks will continue to be thepreferred sensor-network development strategy.Developers will likely start with generic TinyOS pro-tocol implementations, then customize as needed tosatisfy application-specific requirements.

ConclusionThe age of ubiquitous sensing and actuation is beingfueled by Moore’s Law and the development ofadvanced wireless sensor-networking platforms.Hardware can be used to deploy data-collection net-works capable of operating for years without main-tenance in remote, often hostile, environments. Ascapabilities improve, these systems will thus be ableto automatically act on sensor data to manage ourenvironment for us.

Most current sensor-networking deploymentsinclude square-inch-size generic sensor devices thatrepresent an interconnected mesh tied to the Internetthrough one or more gateway-class devices. Moreadvanced networks include high-bandwidth sensornodes capable of dealing with complex data streams,including voice and video. Alternatively, they mayinclude tiny special-purpose sensor nodes that are justmillimeters on a side and weigh only a few gramseach. While the capabilities, cost, and size of eachclass of device will change with technologicaladvances, these four fundamental classes of device willlikely remain for the foreseeable future.

Integral to the performance of sensor-networknodes is the software supporting them. Sensor-net-work applications require precision control over theunderlying hardware in order to meet the strict powerlimitations they must satisfy. Current development

efforts focus on two software platforms for use in wire-less sensor networks. TinyOS provides the precise,efficient, low-level control demanded by both general-and special-purpose networking nodes. In contrast,special kernel modifications have been added to Linuxto enable it to support gateway and high-bandwidth-class device operation. Combined with the hardwareplatforms, TinyOS and embedded Linux are togetherbeing shaped into a powerful toolbox for buildingwireless sensor-network applications.

References1. Gay, D., Levis, P., von Behren, R., Welsh, W., Brewer, E., and Culler,

D. The nesC language: A holistic approach to network embedded sys-tems. In Proceedings of the ACM SIGPLAN 2003 Conference on Pro-gramming Language Design and Implementation (San Diego, CA, June9–11, 2003).

2. Girod, L., Elson, J., Cerpa, A., Stathopoulos, T., Ramanathan, N., andEstrin, D. Em*: A Software Environment for Developing and DeployingWireless Sensor Networks. Tech. Rep. 0034, Center for Embedded Net-worked Sensing, UCLA Computer Science Department, Los Angeles,Dec. 16, 2003.

3. Hill, J. and Culler, D. System Architecture for Wireless Sensor Networks.Ph.D. thesis, University of California, Berkeley, May 2004; see www.jlh-labs.com/jhill_cs/jhill_thesis.pdf.

4. Hill, J. and Culler, D. Mica: A wireless platform for deeply embeddednetworks. IEEE Micro. 22, 6 (Nov./Dec. 2002), 12–24.

5. Hill, J., Szewczyk, R., Woo, A., Hollar, S.,Culler, D., and Pister, K. Sys-tem architecture directions for network sensors. In Proceedings of the 9thInternational Conference on Architectural Support for Programming Lan-guages and Operating Systems (ASPLOS2000) (Cambridge, MA, Nov.12–15, 2000).

6. Levis, P. and Culler, D. Maté: A virtual machine for tiny networked sen-sors. In Proceedings of the 10th International Conference on ArchitecturalSupport for Programming Languages and Operating Systems (ASP-LOS2002) (San Jose, CA, Oct. 5–9, 2002).

7. Madden, S., Szewczyk, R., Franklin, M., and Culler, D. Supportingaggregate queries over ad-hoc wireless sensor networks. In Proceedings ofthe Workshop on Mobile Computing and Systems Applications (New YorkJune 20–21, 2002).

8. Pister, K., Kahn, J., and Boser, B. Smart Dust: Wireless Networks of Mil-limeter-scale Sensor Nodes. Electronics Research Laboratory ResearchSummary, 1999.

Jason Hill ([email protected]) is president and CEO of JLH Labsin Capistrano Beach, CA.Mike Horton ([email protected]) is president and CEO ofCrossbow Technology, Inc. in San Jose, CA. Ralph Kling ([email protected]) is a principal researcherand leader of the Intel Mote project at Intel Research and the SystemsTechnology Laboratory at Intel Corp. in Santa Clara, CA.Lakshman Krishnamurthy ([email protected]) is a senior staff engineer in the Communication TechnologyLab at Intel Corp. in Hillsboro, OR.

Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full cita-tion on the first page. To copy otherwise, to republish, to post on servers or to redis-tribute to lists, requires prior specific permission and/or a fee.

© 2004 ACM 0001-0782/04/0600 $5.00

c


Documents

The platforms enabling wireless sensor networks