Simulation of Wireless Sensor Networks Using TinyOS- A case Study Swarup kumar Mitra †, Ayon Chakraborty* ,Subhajit Mondal* , M.K.Naskar * † MCKV Institute of Engineering 243 ,G.T.Road Liluah(N) Howrah -711204
* Advanced Embedded system Laboratory ,Jadavpur University.
Abstract: Implementation of wireless sensor network applications demands a new set of tools to aid the programmers. A number of simulation platforms developed so far provides varying degrees of energy and delay optimization details for understanding the performance of a sensor network. To relate however, none of these schemes have been simulated with one of the most important aspects of sensor application design that of power consumption. We wanted an approach by which a sensor network can be simulated by utilizing motes. In this paper, we present a case study, where each sensor mote broadcast a number between 1 and 7. The mote whose id matches with the number it receives, turns on its Leds to the received signal value. We have used TOSSIM [1], a well known simulator for wireless sensor networks, for our simulation. It can simulate with nesC[8] source code in TinyOS[2] environment, subsequently which may be used for real test bed situation without any significant modifications. Keywords : Wireless sensor network, sensor motes , TinyOS, TOSSIM
1. Introduction The combination of technological advances in integrated circuitry, MEMS, communication and energy storage has driven the development of low-cost, low-power wireless sensor nodes. Networking many nodes through radio communication allows data collection via multi-hop routing, but the practical limits on available power and the lack of global control present challenges. Power is one of the dominant problems in wireless sensor networks today. Constraints imposed by the limited energy stores on individual nodes require planned use of resources, particularly the radio. Sensor network energy use tends to be particularly acute as deployments are left unattended for long periods of time, perhaps months or years. Communication is the most costly task in terms of energy. At the communication distances, typical in sensor networks, listening for information on the radio channel costs about the same as data transmission. Worse, the energy cost for a node in idle mode is approximately the same as in receive mode. Low power RF design have enabled the development of inexpensive low power sensors with significant computational capability, like the PEGASIS [3], LEACH[4]. These low cost sensors are often networked for high quality, fault tolerant and reliable environment monitoring as well as to detect unwanted intrusions and fault diagnosis of machines. Applications of sensor networks may vary widely from climatic data gathering, seismic and acoustic underwater monitoring to surveillance and national security, military and health care. The sensor networks are required to transmit gathered data to the base station (BS) or access point where the data can be processed. It is often undesirable or infeasible to replace or recharge sensors. Understanding power consumption is especially critical for sensor networks operating on limited power reserves, such as batteries or solar cells. Sensor network designers need the ability to obtain accurate and dependable power consumption figures to tune their applications before deployment in real environments. Apart from aggregate power consumption over time, the pattern of power load is important to consider, as this affects the ability of the power source to deliver adequate energy over time. Existing simulation environments allow researchers to study dynamics such as communication overheads within the network, but no comparable tools exist for practical feasibility of the network. Moreover, simulating the behavior of each sensor node at the level of
CPU cycles or packet size does not scale for networks of considerable size. This produces a picture of power consumption which is necessary for analysis of hot spots, or of variations in power usage under changes in the environment or network topology. The organization of our paper follows section 2 discuss the necessity of network simulation , section 3 gives the details of the case study and section 4 concludes the paper.
2.1 The Necessity of Network Simulation The emergence of wireless sensor networks brought many open issues to network designers. Traditionally, the three main techniques for analyzing the performance of wired and wireless networks are analytical methods, computer simulation, and physical measurement. However, because of many constraints imposed on sensor networks, such as energy limitation, decentralized collaboration and fault tolerance, algorithms for sensor networks tend to be quite complex and usually defy analytical methods that have been proved to be fairly effective for traditional networks. Furthermore, few sensor networks have come into existence, for there are still many unsolved research problems, so measurement is virtually impossible. It appears that simulation is the only feasible approach to the quantitative analysis of sensor networks. The necessity of simulation are as follows:
• • • • •
Tests system configurations that are difficult/impossible to construct. Observes system performance and interactions difficult to observe in actual deployment Environment (Wild Cense). Tests the quality and reliability of algorithms for Sensor Network (data processing, routing). Compares different design strategies to choose the best one. Accurate and scalable simulation brings down cost and time of development, thus accelerating pace of research in that area. In short, simulation for Sensor Network allows for savings on time, money and human effort.
2.2 Background Wireless sensor networks are composed of large numbers of tiny resource-limited devices (motes). A first application of these networks is data collection in uncontrolled environments, such as nature reserves [6] or seismically threatened structures [7]. Four key features have emerged in networks we have deployed: interaction with the local environment though sensors, communication via a wireless network, lifetime requirements of months to a year, and physical inaccessibility. For our simulation we have used TOSSIM[1] which being programmed in NesC[8], and compiled in TinyOS[2] environment . (i) NesC [8] A key focus of nesC[8] is holistic system design. Mote applications are deeply tied to hardware, and each mote runs a single application at a time. This approach yields three important properties. First, all resources are known statically. Second, rather than employing a general-purpose OS, applications are built from a suite of reusable system components coupled with application-specific code. Third, the hardware/software boundary varies depending on the application and hardware platform; it is important to design for flexible decomposition. There are a number of unique challenges that nesC[8] must address: (i) Driven by communication with environment (ii) Inadequate resources
(iii) Consistency (iv) Soft real-time requirements (ii) TinyOS TinyOS [2] is an open source operating system specifically designed for network embedded sensor networks. It features component – based architecture which enables rapid innovation and implementation while minimizing code size as required by severe memory constraints inherent sensor network. TinyOS has a programming model tailored for event-driven applications as well as a very small footprint (the core OS requires 400 bytes of code and data memory, combined). Two of our motivations in designing nesC were to support and evolve TinyOS’s programming model and to re implement TinyOS in the new language. TinyOS has several important features that influenced nesC’s design: a component-based architecture, a simple event-based concurrency model, and split-phase operations. (i) Component-based architecture (ii) Tasks and event-based concurrency (ii) Split-phase operations (iii) TOSSIM : TOSSIM[1] is a event discrete simulator for TinyOS applications. It works by replacing components with simulation implementations. TOSSIM is a library: you must write a program that configures a simulation and runs it. TOSSIM supports two programming interfaces: Python and C++. Python allows you to interact with a running simulation dynamically, like a powerful debugger. However, since the interpretator can be a performance bottleneck when obtaining results, TOSSIM also has a C++ interface. Usually, transforming code from one to the other is very simple. TOSSIM currently does not support gathering power measurements. This allows users to debug, test, and analyze algorithms in a controlled and repeatable environment. As TOSSIM runs on a PC, users can examine their TinyOS code using debuggers and other development tools. Similarly, TOSSIM can replace a packet-level communication component for packet-level simulation, or replace a low-level radio chip component for a more precise simulation of the code execution. TOSSIM is a discrete event simulator. When it runs, it pulls events of the event queue (sorted by time) and executes them. Depending on the level of simulation, simulation events can represent hardware interrupts or high-level system events (such as packet reception). Additionally, tasks are simulation events, so that posting a task causes it to run a short time (e.g., a few microseconds) in the future. 3. A Case Study : NesC is a component based C dialect used for programming a mote. These components uses local name space similar to objects in a programming language. Due to inadequate resources of 8KB of program memory and 512 bytes RAM, having global name space and runtime function call is prohibitive. Building NesC program involves declaring the components and wiring users to providers, which makes fast compilation .TinyOS and NesC is able to take handle this approach as user interface is of no need in a sensor node, for they are composed of embedded Computers with well defined and predefined uses. A mote can run only one single application at a time. We present an application at “ Bcast Address to Leds “ to run on mica family. The application assumes that seven motes are available, having mote ids ranging from 1 to 7. Each mote broadcast numbers between 1 and 7. The mote whose id matches with the number it receives, turns on its Leds to signal the value. Any nesC needs two types of components module and configuration. We have used TOSSIM, a well known simulator for wireless sensor networks, for our simulation. It can
simulate with TinyOS source code on real test bed without any significant modifications. TOSSIM is executed based on the event driven model and its simulator clock unit is 4Mhz, on instruction cycle of mica. Any interrupts and signals are stored into the event queue of TOSSIM and total management is based on global clock unit. Each node is randomly started at initially to avoid artificial synchronization. We need to specify a network topology for the nodes (motes) to communicate with each other. Real time RF noise and interference is incorporated in the simulation using the closet pattern Matching (CPM) algorithm. A noise trace is provided to CPM, using the traces taken from Meyer Library at Stanford University, in the file “meyer-heavy.txt”. The radio connectivity data between the nodes is stored “topology.txt” file[10], as 1, 2 , -54.0 (sender-receiverattenuation) , which signifies that when 1 transmits , 2 hears it at -54dBm . For programming any application we have to write the configuration file and module file with .nc extension. The interface being used to communicate between the file or performs the necessary wiring. The header file produces information about the set of data structures written depending upon the application requirement. In the make file the path to be set for the file which uses the application to be simulated or build. (i) The header files defines, the set of data structures used/involved, say the message structure or defining , the payload area etc. It can also enumerate constants as needed enum { AM_BCASTADDRESSTOLEDS = 6, TIMER_PERIOD_MILLI = 500 }; typedef nx_struct my_message_structure_t { nx_uint8_t number ; nx_uint8_t node_id; } my_message_structure_t; nx =external types i.e., hardware independant
The enum defines the port address and the timer period. (ii) The configuration file does the necessary linking and wiring of the components to the interfaces. In our example we have used the components to the interfaces. In our simulation we have used the components MainC, LedsC, and a generic component TimerMilliC(), which provides the interfaces , Boot, Leds, and instances of TimerMilliC() respectively. components MessageSendingC, MainC, LedsC , new TimerMilliC() as Timer0 ;
All the components mentioned above may be used as interfaces elsewhere MessageSendingC.Leds LedsC.Leds ; MessageSendingC.Timer0 Timer0 ; The left hand side of the arrow denotes user and right hand side of the same denotes provider. The wiring denotes, that the file MessageSendingC would be used using the dot interface, in the same way. LedsC uses Leds interface. Now the file now to be written is the module file where our application is mainly programmed . In our case study our primary objective is to transmit a sample count value. While regarding the data transmission part, we use the ‘ AM Send ‘ and ‘ Packet’ interfaces , both being provided
by the component ‘ AM SenderC ‘ . As discussed earlier the necessary wiring for this in configuration file would be Message Sending C.AMSend AMSenderC. AMSend ; Message Sending C.AMPacket AMSenderC.Packet ; For starting and stopping operation of radio , we choose the split control . interface provided by CC2420 ActiveMessageC components ( for the micaz motes). Now to start with , the timer should only be started after the system has booted and the radio has started successfully . event void Boot.booted() { call . splitControl.start(); } If the radio started successfully , Start done , a command in the split Control . Interface would be automatically involved with parameter error_t set to SUCCESS ; otherwise we will again try to start the radio event void splitControl.startDone(error_t err){ if(err == SUCCESS) call Timer0.startPeriodic(TIMER_PERIOD_MILLI); else call split.Control.start(); This ensures that the software doesn’t start , until the radio is successfully turned ON. Thus the clock operating at 4 Hz will fire every 500ms , and we implement the event fired(), such that it transmits the message at that time Event void Timer0.fired () { if (!busy) { my_message_structure_t *ptr2pkt =(my_message_structure_t *)( call Packet .get data, NULL) ;
Payload(&
/* setting a pointer to the payload area */ Ptr2pkt number = counter ; if(call AMSend .send ( AM_BROADCAST_ADDR, &data, sizeof (my_message _structure_t)) == SUCCESS) busy = TRUE ;} } while interpreting the interfaces, we find AMSend has an event , sendDone , thus it has to be implemented . event.void AMSend .send Done (message_t *bufptr, error_t err) { if ( &data ==bufptr) { busy = FALSE ;}} When the message sending is done , the boolean variable busy is set to TRUE , and busy = FALSE , denotes radio has finished sending . Similarly on the receiving side, after receiving the message, the mote leds are to be set to that count. Here message_t is the default message structure in TinyOS2.0.
Event message *Receive.receive ( message_t *msg, void *payload , uint8_t siza) { If ( size = size of(my_message _structure_t)) { my_message _structure_t *ptr2pkt = (my_message _structure_t *)payload ; call Leds.set(ptr2pkt number ) ; } return msg ; }
4. Conclusion We have approached with a minor application of a sensor network. Our simulation work produces a simple an elegant process by which a network could be processed by hardware being demonstrated in a TOSSIM environment. In future development we can implement the different applications of sensor network. Its practical feasibility can be tested in a simulation environment(TOSSIM).
5. References [1] Philip Levis and Nelson Lee
[email protected] TOSSIM: A Simulator for TinyOS Networks [2]
Philip Levis ,TinyOS Programming , June 28, 2006
[3] S.Lindsey, C. S. Raghavendra : PEGASIS: Power Efficient GAthering in Sensor Information Systems, Submitted to ICC 2001 [4] W. Heinzelman, A. Chandrakasan, H. Bal Krishnan: Energy- Efficient Communication Protocol for Wireless Micro sensor Networks, IEEE Proc. Of the Hawaii International Conf. on System Sciences, January 2000. [5] P. Levis, N. Lee, M. Welsh, and D. Culler. TOSSIM: Accurate and Scalable Simulation of Entire TinyOS [6] A. Mainwaring, J. Polastre, R. Szewczyk, D. Culler, and J. Anderson. Wireless Sensor Networks for Habitat Monitoring. In Proceedings of the ACM International Workshop on Wireless Sensor Networks and Applications, Sept. 2002 [7] Lab Notes: Research from the College of Engineering, UC Berkeley. Smart buildings admit their faults., 2001. http://coe.berkeley.edu/labnotes/1101.smartbuildings.html.Applications To appear in Proceedings of the First ACM Conference on Embedded Networked Sensor Systems [8] David Gay, Philip Levis, David Culler, Eric Brewer, nesC 1.1 Language Reference Manual [9] www.tinyos.net [10] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. E. Culler, and K. S. J. Pister. System Architecture Directions for Networked Sensors. In Architectural Support for Programming Languages and Operating Systems, pages 93–104, 2000. TinyOS is available at http://webs.cs.berkeley.edu
