SENSOR: AN ALGORITHMIC SIMULATOR FOR WIRELESS SENSOR NETWORKS Mount, S., Newman, R. M.*, Gaura, E., Kemp, J. Cogent Computing ARC, Coventry University, Priory St, CV1 5FB, UK *Corresponding author: R.M.Newman, +44 (0)24 7688 8583, +44 (0)24 7688 8585,
[email protected] Abstract: This paper presents SenSor, a simulator designed to address the need for a multi-domain unifying simulation tool aimed at algorithm development by the end user of a wireless sensor network (WSN). Its design reflects the cross-domain nature of this field, and the consequent mix of concerns and requirements of endusers in real-world sensing applications. Keywords: WSN, simulation, application-oriented
INTRODUCTION Research on the topic of wireless sensor networks (WSNs) is currently one of the most active areas of sensing research, having been driven by visions of grand scale 'dream applications', the most famous being Pister's 'Smart Dust' [7], or, more recently, in the UK, 'Speckled Computing' [1]. Although these activities are not directly focussed on the production of deployed sensing systems, real WSNs - which do provide the opportunity to address otherwise intractable sensing problems are feasible today, particularly in the domain of sensing of data continuously over extended periods of time, or the sensing of multivariate data in which the source of the data is mobile. Two such systems which have been successfully deployed are ZebraNet [6] and MAVES [4]. In ZebraNet the authors have deployed a WSN of thirty nodes to monitor wildlife over very large distances (up to thousands of square kilometers) at the Mpala Research Centre in Kenya. Animals carry custom motes which include GPS, flash memory, wireless transceivers and a CPU. Light sensors are used to give an indication of the current environment, with each node logging its sensor readings every three minutes. Whenever a node is in communication range of another node, sense data is exchanged, which is then relayed to a mobile base station (e.g. In a plane or car) as it passes. By contrast, [4], describes the application of VanGo (a software system for data collection using flexible transcoding) applied to two very different application domains: acoustic collection and the monitoring of neural activity in rats. Again, the networks described are small (between eight and fourteen nodes), using the TelosB mote. The VanGo system allows users to specify (at run-time) a variety of sophisticated signal processing algorithms to be applied to incoming sense data. Unusually, VanGo only allows in-node signal processing which combine to allow (for example) acoustic voice data to be separated from background noise. Both ZebraNet and MAVES have had to address common WSN concerns such as node locationing, network discovery and topology management, adhoc routing and fault management. That such implementations have been possible whilst 'Smart Dust' and 'Speckled Computing' are still distant dreams is due to the fact that, in common with many real-life WSN systems, ZebraNet and
MAVES have comparatively low aspirations in terms of the number of nodes in the network, relatively large hardware packages (ZebraNet's sensor package weighs pounds) and relatively low sampling rates. Future field sensing WSNs, of this type, may be expected to be very much more complex in terms of behaviour than previous sensing systems, for four reasons: i) much greater complexity of applications ii) distribution of application level functions into the network. iii) distributed systems requirements. iv) esoteric sensor hardware Each of these is discussed in the sections below.
COMPLEXITY OF APPLICATIONS
In the types of application discussed above, the applications themselves are designed to extract complex information from raw data. Data fusion and inference systems are often part of the specification of these systems.
APPLICATION LEVEL DISTRIBUTION Communication bandwidth and power restrictions dictate that much of what would traditionally be applications level processing be performed within the sensing network. Consequently, parallel distributed versions of the programs must be developed.
DISTRIBUTED SYSTEMS REQUIREMENTS Organisation of a large network of collaborating sensing nodes is a complex matter in its own right, and the program overhead it entails cannot always be made transparent to the applications system. Moreover, such applications, although complex, are expected to achieve extremely long up-times without human intervention. The distribution of algorithms must not only guarantee to introduce no errors, the system must self-manage faults in hardware.
ESOTERIC SENSING HARDWARE Often these systems make use of new classes of sensor which require complex signal processing simply to produce a measurement. (One of the big advantages of WSN in these applications is availability of a local processor close to the transducer). One example of such a sensor is a Coriolis Flow Meter [5]. Such a meter has operational advantages compared with other types, in terms of physical robustness and simplicity, but requires both carefully controlled drive signals and interpretation of the phase and amplitude of the
flow oscillation resulting from them. Particularly in a wireless networked environment, in which data bandwidth is at a premium, it is the resultant signal (the level of the flow), rather than the direct measureand (the flow oscillation) that should be transmitted. This can only be achieved using a local processor to derive the measurement.
SIMULATION IN WSN DEVELOPMENT As a result of the above considerations, the design of WSNs is a very different undertaking from that of more traditional sensing systems, often involving multidisciplinary teams rather than a single sensor engineer. Frequently there is a considerable amount of software to produce and integrate into the network, which must be tested before it is deployed. For this purpose, much of the current research in WSN has depended on simulation, and there have been a large number of simulators produced. Network-level WSN simulators are often generic discrete event network simulators (such as OMNet++ [10]) or are derived from one, (such as ns-2), with additions which cater particularly for WSNs. GloMoSim [14] and SensorSim [11] are examples of the latter category. GloMoSim has a number of models for radio propagation, MAC protocols, routing protocols, and so on. However, it is effectively limited to simulating IP networks and does not provide support for sensing or actuation. SENSE [13] is similar, although the authors of [13] argue that their component-based framework is an improvement over the common object-oriented paradigm as it offers looser coupling between simulation components. J-SIM [9], SENS [12] and Sidh [3], however, were all designed from the ground-up to model WSNs. JSIM is a network-level component-based simulation framework, having support for sensing and physical phenomena and mobile WSNs. SENS is similarly equipped, although the support it provides for physical phenomena is limited to sound. Sidh [3] is notable because the authors claim to be able to model thousand-node networks “faster than realtime” on a desktop PC. Sidh is component based and supports communication media; sensors and actuators; environmental conditions; protocols; and applications. TOSSIM [8] and ATEMU [2] differ from networklevel simulators in that they have been designed specifically to simulate the MICA family of motes, from Berkeley. This has the advantage of allowing a user to write one application which can run both on a simulator and on hardware, but equally the disadvantage of forcing the user to write code which is specific to the language and design patterns of the platform. TOSSIM is, perhaps, best suited to being used towards the end of the software development cycle, when algorithms have already been designed (and perhaps simulated elsewhere) and a hardware platform specified and procured. What is evident from this brief survey is that generally these simulators have been designed originally to address horizontally stratified concerns. At their inception, the design was driven by the need to evaluate some specific part of the
very large set of problems that need to be addressed in WSN (for instance, network discovery or power usage), although many of them have since expanded to become in some ways 'general purpose'. One disadvantage of this evolution is that the user of such a system is often forced to make premature designed decisions about their application. In the case of network simulators this often has to do with protocol choice, packet structures, and so on, whereas with hardware simulators the designer is forced to choose a platform for deployment. Early in the design cycle, when low-level concerns may cause premature optimisations this is undesirable, as the user often wants to compare algorithm designs for one aspect of WSN operation (such as fault management) in isolation to some or perhaps all other services.
TOP LEVEL SIMULATION One horizontally stratified concern that has had relatively less attention is that of the end application designers. As has been discussed above, it is often the case that real-application sensing devices are not simply 'plug and play', they require advanced signal processing to operate. This signal processing must be integrated with the other concerns of the operation of the WSN, such as network discovery, localisation, fault management and so on. Currently, it is not the case that pieces of software handling all of these concerns can be simply brought together and expected to work, due to the conflicting constraints of a real WSN node. The process of integration can be considerably aided by simulation, but the requirements of a simulator to fit this need are somewhat different from those of the simulators listed in the previous section. Most importantly, such a simulator needs to be flexible in both what the user may simulate and at what level of abstraction. Some applications (such as acoustic monitoring) may utilise fixed nodes where each sensor is placed at a known location. Other applications (such as those where sensors are embedded in smart materials) may require nodes to locate themselves on start-up. Still others (perhaps where a permanent energy source is available) may be able to use GPS or similar services which reside outside the network. A generic, top-level simulator needs to be able to support all such applications, providing support for locationing algorithms, a method by which each node may be assigned a physical (3d) location on start-up and a method by which external services may be represented. More importantly, such services will be expected to evolve as more of the application is simulated. An initial simulation for the acoustic monitoring example may begin with the designer writing a locationing module. However, it may be that early on in development it is important to write simple modules to represent sound sensing, although it may not be important to simulate sensing realistically until signal processing is to be designed. Ideally, a top-level simulator will allow for some WSN services to be absent and those present to be represented at different levels of accuracy as the application design develops.
SENSOR – AN ALGORITHMIC TOPLEVEL SIMULATOR SenSor provides a workbench for prototyping algorithms for wireless sensor networks. It consists of a graphical user interface (see Figure 1) and a set of base classes which are extended by the user to create a simulation. Although the authors have used an object oriented approach to the design, care has been exercised to make the base classes very loosely coupled. The only classes which must be subclassed to create a simulation are Sensor, which represents an individual WSN node and Simulation, which should contain a list of Sensor objects to appear in the simulation. Anything else, such as specialised packet types, special probe types such as microphones, models of physical quantities such as RSSI, and so on, are optional.
entire application. This problem forms part of our motivation for writing a high-level simulator: users can prototype part of an entire application to test for scalability without having to code details which may be irrelevant to the particular part of the design they are working on. Application design for wireless sensor networks usually involves interfacing with software outside the network. In a typical application, such as factory automation, the nodes in the network collaborate to analyse their data and then make a decision to actuate some external system. Alternatively, in applications such as environmental sensing, data may be logged and aggregated within the network and then sent to an external device to be displayed to users. In a high-level simulator such as SenSor users can write custom code to interface with external applications. For example, the authors have implemented a simulation similar to the environmental sensing scenario, where motes log data from individual virtual probes, then average that data within the network and send it to a mobile phone via a Bluetooth stack.
SENSOR INTERNALS
Figure 1: The graphical user interface of SenSor during a simulation. The graph pane shows broadcast communication between a sensor in the centre of the screen and the rest of a (one-hop) network. The chart pane shows incoming sense data from the selected sensor.
The SenSor GUI (see Figure 1) provides the following features: • a built-in code editor with syntax colouring and folding. • a graph pane on which a representation of the sensor network is drawn. To aid debugging, colour is used to represent the state of each node and the types of packet sent across the network. Users may drag and drop nodes around the pane which automatically changes the internal representation of their geographical location. This is particularly useful for experimenting with the robustness of locationing algorithms. • a chart pane where individual data can be plotted during the simulation. Once a node has been selected on the graph pane its current data is displayed on the chart. The legend, axes, labels and data plotted during the simulation are all set by the user in the simulation code. A major concern for the designer of a wireless sensor network is the scalability of algorithms. It is almost impossible to predict how well a protocol or algorithm will scale to many hundreds or thousands of nodes without either prototyping or deploying an
From the perspective of the user, a sensor in SenSor can be thought of as a scheduler with shared memory for scheduled tasks to communicate over. It is important for SenSor to accurately model the distributed nature of WSNs, since in a deployed system bugs arising from concurrency and distribution can often be the most difficult to isolate and analyse. SenSor models distribution in two ways. Firstly, communication packets are shallow copied by each receiving sensor. This is in contrast to some other simulators such as SENSE [13], where every simulated node increments a reference count on receipt of a packet and only one copy of the packet is kept in memory. Secondly, SenSor ensures that each simulated sensor runs in it's own thread. Since simulations are displayed in a GUI, which expects the interface to run in a single thread (as is standard in GUI widget sets) the concurrency within simulations needs to be transparent to the user interface. In SenSor, a Python decorators called @wxThreadSwitch was created to manage interaction between simulations and the GUI event queue. When an internal method, such as AddSensorNode which adds a circle to the graph pane, is declared at runtime an instance of the wxThreadSwitch type is applied as a wrapper to the method. When the method is called, the wxThreadSwitch instance places the code to be executed on the wxPython event queue. When the new event is executed by wxPython's event manager the wxThreadSwitch instance checks to ensure that it is now running in the main thread of the GUI. It then blocks the caller and executes the original method (AddSensorNode in the above example) returning the result (or raising an exception) to the caller, which it unblocks. Using this technique one can keep a minimal amount of concurrency management within the GUI code and each simulated sensor can run in its own thread with no extra lines of code. Most importantly, concurrency control is entirely transparent to the
users and no threading or concurrency related code need appear in any simulation code.
a commitment is made to fine tuning low level, device dependent code.
SenSor has been used in a number of situations by several users including researchers and undergraduate Computer Science students. Our experience has shown that SenSor has a very shallow learning curve and that undergraduate students (with no WSN experience) can begin writing simulations within a day. Equally, many simulations are short (in terms of effective LOCs), which is helped by a choice of high-level implementation language and a loosely coupled set of base classes. For example, the full source for a simple “Hello World!” simulation, in which each node simulates sense data collection, communication (using custom packet formats) and actuation takes less than one hundred (effective) lines of Python code. SenSor has been found to be of particular value in developing algorithms by refinement. For example, the authors have implemented a series of comparative simulations of locationing algorithms, where ranging was implemented by comparing the time of flight of RF and acoustic signals: 2d locationing, ideal RF: Here, a two dimensional version of the locationing algorithm was implemented with ideal RF ranging. This enabled an initial implementation of the algorithm to be tested for correctness, as (without noise) the estimated location of sensors was expected to be equal to their exact locations. 2d locationing, noisy RF: Here, the same locationing code was used, replacing the declaration of the ranging mechanism. Since new ranging algorithms can be implemented simply by subclassing the default ranger, a variety of noise types could be compared. 2d locationing, in-network processing: The locationing algorithms simulated by the authors were also implemented on the MICA series of motes. Interestingly, the MICA2 motes did not have enough on-board memory to perform a matrix solution of a system of linear equations required to compute estimated locations. SenSor allowed the authors to experiment with in-network processing which would not have been possible with the particular hardware available. Since SenSor allows the arbitrary replacement of any internally provided WSN service, specific aspects of the locationing algorithm in question could be isolated and compared in a systematic way.
1.Arvind D K, Speckled Computing, in Proceedings of the NSTI Nanotechnology Conference and Trade Show (Nanotech ’05), Vol 3, pp 351354, ISBN 097679852 2, Anaheim CA, USA, May 2005 2.ATEMU – Sensor Network Emulator / Simulator / Debugger http://www.cshcn.umd.edu/research/atemu/ 3.Thomas W. Carley Sidh: A Wireless Sensor Network Simulator . University of Maryland Technical Report 88. 2005. http://techreports.isr.umd.edu/reports/2005/TR_2005 88.pdf 4.Ben Greenstein, Alex Pesterev, Christopher Mar, Eddie Kohler, Jack Judy, Shahin Farshchi, Deborah Estrin. Collecting HighRate Data Over LowRate Sensor Network Radios. CENS Technical Report 55. 2005. 5.Manus Henry, Hoi Yeung, Wade Mattar, The Two Phases of Coriolis flow InTech, ISA, 01 Jan 2005. 6.Philo Juang, Hidekazu Oki, Yong Wang , Margaret Martonosi, LiShiuan, Peh, and Daniel Rubenstein, EnergyEfficient Computing for Wildlife Tracking: Design Tradeoffs and Early Experiences with ZebraNet. In Proceedings of the Tenth International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOSX). October, 2002. San Jose, CA. 7.J. M. Kahn, R. H. Katz and K. S. J. Pister, Next Century Challenges: Mobile Networking for Smart Dust. In proceedings of the ACM/IEEE International. Conference on Mobile Computing and Networking (MobiCom) Seattle, WA, USA. August 1999 8.Philip Levis, Nelson Lee, Matt Welsh, and David Culler TOSSIM: Accurate and Scalable Simulation of Entire TinyOS Applications. In Proceedings of the First ACM Conference on Embedded Networked Sensor Systems (SenSys 2003). pp126–137 9.John A. Miller, Andrew F. Seila and Xuewei Xiang, The JSIM WebBased Simulation Environment. Future Generation Computer Systems (FGCS), Special Issue on WebBased Modelling and Simulation, 17(2),October 2000 Elsevier NorthHolland pp. 119133 10.OMNeT++ Discrete Event Network Simulation System http://whale.hit.bme.hu/omnetpp/ 11.S. Park, A. Savvides, and M. Srivastava. SensorSim: A simulation framework for sensor networks. In Proc. of the ACM international Workshop on Modeling, Analysis and Simulation of Wireless and Mobile Systems, 2000. 12.SENS: A Sensor, Environment and Network Simulator http://osl.cs.uiuc.edu/sens/ 13.Boleslaw Szymanski and Bulent Yener, editors, Advances in Pervasive Computing and Networking Kluwer Academic Publishers, (2004), Chapter 14. 14.Xiang Zeng, Rajive Bagrodia, and Mario Gerla, GloMoSim: A library for parallel simulation of large scale wireless networks, Proceedings of the 12th Workshop on Parallel and Distributed Simulations, PADS '98, May 2629, in Alberta, Canada, 1998.
EXPERIENCE WITH SENSOR
CONCLUSIONS
The paper presented the case for a simulator working at a higher abstraction level than the many simulators currently in use in the WSN domain. To the authors’ knowledge, SenSor is the first simulator of this kind and also the first to be opensourced in the UK. The production of the embedded software within WSNs is known to be challenging. The use of the simulator at the level proposed allows experimentation with and characterization of the algorithms which are the basis of the software in an effective manner, before
REFERENCES
