Implementing Software on Resource-Constrained Mobile Sensors: Experiences with Impala and ZebraNet Ting Liu Christopher M. Sadler Pei Zhang Margaret Martonosi Departments of Electrical Engineering and Computer Science Princeton University {tliu, csadler, peizhang, mrm}@princeton.edu ABSTRACT puter Systems Organization]: Special-purpose and App- ZebraNet is a mobile, wireless sensor network in which nodes lication-based Systems—Microprocessor/Microcomputer Ap- move throughout an environment working to gather and pro- plications; Real-time and Embedded Systems; D.4.4 [Opera- cess information about their surroundings [10]. As in many ting Systems]: Communications Management—Buffering; sensor or wireless systems, nodes have critical resource con- Message Sending; Network Communication; D.4.7 [Operat- straints such as processing speed, memory size, and energy ing Systems]: Organization and Design—Distributed Sys- supply; they also face special hardware issues such as sens- tems; Real-time Systems and Embedded Systems ing device sample time, data storage/access restrictions, and wireless transceiver capabilities. This paper discusses and General Terms evaluates ZebraNet’s system design decisions in the face of Design, Measurement, Performance a range of real-world constraints. Impala—ZebraNet’s middleware layer—serves as a light- Keywords weight operating system, but also has been designed to en- courage application modularity, simplicity, adaptivity, and Sensor Networks, Middleware System, Operation Schedul- repairability. Impala is now implemented on ZebraNet hard- ing, Event Handling, Network Communications ware nodes, which include a 16-bit microcontroller, a low- power GPS unit, a 900MHz radio, and 4Mbits of non-volatile 1. INTRODUCTION FLASH memory. This paper discusses Impala’s operation Energy-aware mobile sensor networks will make a signif- scheduling and event handling model, and explains how sys- icant impact on society within the next decade. The tech- tem constraints and goals led to the interface designs we nology has numerous military and civilian applications that chose between the application, middleware, and firmware can save lives and improve our overall quality of life. These layers. We also describe Impala’s network interface which networks are typically comprised of a low power microcon- unifies media access control and transport control into an troller capable of limited information processing, sensors to efficient network protocol. With the minimum overhead capture specific data from the environment, memory to store in communication, buffering, and processing, it supports a collected data, and a radio to transmit data between nodes. range of message models, all inspired by and tailored to Ze- Sensor networks can be comprised of thousands of nodes braNet’s application needs. By discussing design tradeoffs communicating with each other to relay data and to perform in the context of a real hardware system and a real sensor complex distributed calculations. Individual nodes must be network application, this paper’s design choices and perfor- extremely energy-efficient as once they are deployed in the mance measurements offer some concrete experiences with environment they are very difficult, if not impossible, to software systems issues for the mobile sensor design space. reacquire. Additionally, depending on their size, the envi- More generally, we feel that these experiences can guide de- ronment in which they are deployed, and their power con- sign choices in a range of related systems. sumption, each node can be extremely unreliable. Programmers for these systems must make a concerted Categories and Subject Descriptors effort to establish efficient, dependable communications be- C.0 [Computer Systems Organization]: General—Hard- tween nodes. Radio transmissions must be minimized as ware/Software Interfaces; System Architectures; C.3 [Com- each byte transmitted consumes around two orders of mag- nitude more energy than each computation on the low power microcontroller. Additionally, protocols must account for the unreliable nature of the network as nodes can fail or Permission to make digital or hard copies of all or part of this work for simply move out of range during transmission. Steps must personal or classroom use is granted without fee provided that copies are be taken to ensure that the network can rapidly adapt to not made or distributed for pro®t or commercial advantage and that copies such changes in its structure. bear this notice and the full citation on the ®rst page. To copy otherwise, to The Princeton ZebraNet Project explores these issues as republish, to post on servers or to redistribute to lists, requires prior speci®c we develop an energy-efficient mobile sensor network to help permission and/or a fee. MobiSYS'04, June 6±9, 2004, Boston, Massachusetts, USA. track zebra migrations in Africa [10]. Individual nodes have Copyright 2004 ACM 1-58113-793-1/04/0006 ...$5.00. been built into collars and deployed on zebras near the Mpala Research Centre in Kenya [17]. Each node is equipped with • Building real working hardware and software has en- a GPS unit in order to log position information. This infor- riched our design decisions and gives us insights we mation is then passed from zebra to zebra using peer-to-peer feel have value to the mobile research community as a protocols until it reaches a base station where it can be pro- whole. cessed and analyzed. Impala—ZebraNet’s middleware layer—serves as a light- The remainder of this paper is structured as follows. Sec- weight operating system, but also has been designed to en- tion 2 gives context for the Impala system by presenting courage application modularity, simplicity, adaptivity, and the ZebraNet system itself and the system constraints. Sec- repairability. A previous study of Impala, prototyped within tion 3 describes the layers and interfaces of Impala. Sec- the HP/Compaq iPAQ pocket PC handhelds, was focused tion 4 discusses the way Impala schedules regular opera- on its middleware support for inherent software modulariza- tions and handles irregular events. In Section 5, we present tion, dynamic software adaptation, and remote software up- Impala’s network interface. Section 6 presents some perfor- date [12]. Impala now is implemented on the ZebraNet hard- mance evaluations. Finally, Section 7 presents related work ware featuring energy-efficient components. Critical issues and Section 8 presents our conclusions. arise concerning implementing software on the real hardware system. Such issues include hardware/software interfaces, 2. THE ZEBRANET SYSTEM system operation scheduling, event handling, and network ZebraNet is a mobile, wireless sensor network system aimed communication support. This paper discusses these issues at improving tracking technology via energy-efficient track- in the context of our implementation experiences, and de- ing nodes and store-and-forward communication techniques scribes how underlying hardware realities impact our design [10]. While ZebraNet’s most immediate focus is wildlife choices. The first test deployment of ZebraNet occurred tracking across large regions with little communications in- in January 2004, and the system has evolved to the point frastructure, its broader goals concern the deployment, man- where the hardware and software layers have become clearly agement, and communications issues for large numbers of defined. both static and mobile sensors. Overall, the contributions of this work are as follows: A ZebraNet hardware node includes global positioning • We built a system architecture with minimal layering system (GPS), a simple microcontroller CPU, a wireless and clean interfaces for resource-constrained mobile transceiver, and non-volatile storage to hold logged data. sensor systems. The Impala middleware layer trans- ZebraNet does not rely on constant communication access forms rough hardware realities into easy application to a base station or other nodes. Instead, it uses periodic perspectives. It allows complex hardware controls and node discovery and node-to-node communication to propa- accesses to be safely exported as convenient services gate data towards the base station in a store-and-forward to applications. It also allows miscellaneous hardware manner. interrupts to be efficiently handled and delivered as a 2.1 Hardware Overview few types of abstract events. The ZebraNet hardware, which is depicted conceptually • We established a system activity model that handles in Figure 1 and pictured in Figure 2, is composed of energy- a mix of regular operations and irregular events for efficient components ideal for use in mobile sensor networks. long-running mobile sensor systems. By having the The major functional components on the board are the mi- best knowledge of the overall system activities, Impala crocontroller, GPS, external FLASH, radio, and battery with uses operation scheduling to achieve the maximum en- solar chargers. ergy conservation without yielding system control to To control the hardware, we selected the Texas Instru- untrusted applications. By processing simple hard- ments Ultra-Low-Power MSP430F149 16-bit microcontroller. ware interrupts in short/atomic routines and handling This chip has 2KB of RAM, 60KB of internal FLASH mem- complex software events in long/preemptable routines, ory, and two serial interfaces [24]. It runs off an uninter- Impala achieves both concurrency and prioritization of ruptible power supply as we expect it to run continuously. system activities. The microcontroller