Simulation in Wireless Sensor Networks

International Journal of Electronics Communication and Computer Technology (IJECCT) Volume 2 Issue 4 (July 2012)

Simulation in Wireless Sensor Networks Sushruta Mishra , Sasmita Mishra, ,Abhishek Kayal, Sandeep Reddy Chudi Department of Computer Science and Engineering IIIT Bhubaneswar Abstract—Simulation tools for wireless sensor networks are increasingly being used to study sensor webs and to test new applications and protocols in this evolving research field. There is always an overriding concern when using simulation that the results may not reflect accurate behavior. Here in this paper a comprehensive study of Simulation is described that also includes types of simulations, emulation steps in simulation and other related issues. Keywords- Wireless Sensor Networks; Simulaor;, Emulator; Testbeds.

I.

INTRODUCTION

Wireless Sensor Networks (WSNs) consist of spatially distributed self-configurable sensors, perfectly meet the requirement. The sensors provide the ability to monitor physical or environmental conditions, such as temperature, humidity, vibration, pressure, sound, motion and etc, with very low energy consumption. The sensors also have the ability to transmit and forward sensing data to the base station. WSNs are bi-directional, enabling two-way communication, which could collect sensing data from sensors to the base station as well as disseminate commands from base station to end sensors Wireless Sensor Network (WSN) is built of several hundreds or even thousands of “sensor nodes”. The topology of WSNs can vary among star network, tree network, and mesh network. Nowadays, the WSN is a hot research topic. Many network details in WSNs are not finalized and standardized. Building a WSNs testbed is very costly. Running real experiments on a testbed is costly and difficulty. Besides, repeatability is largely compromised since many factors affect the experimental results at the same time. It is hard to isolate a single aspect. Moreover, running real experiments are always time consuming. Therefore, WSNs simulation is important for WSNs development. Protocols, schemes, even new ideas can be evaluated in a very large scale. WSNs simulators allow users to isolate different factors by tuning configurable parameters. Consequently, simulation is essential to study WSNs, being the common way to test new applications and protocols in the field. This leads to the recent boom of simulator development. However, obtaining solid conclusions from a simulation study is not a trivial task. There are two key aspects in WSNs simulators: (1) The correctness of the simulation models (2)The suitability of a particular tool to implement the model. The emergence of wireless sensor networks brought many new emerging issues to network designers. Traditionally, the

ISSN:2249-7838

three main techniques for analyzing the performance of wired and wireless networks are analytical methods, computer simulation, and physical measurement. Due to many constraints imposed on sensor net-works, 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 un-solved research problems, so measurement is virtually impossible. It appears that simulation is the only feasible approach to the quantitative analysis of sensor networks .Simulation is the imitation of the operation of a real-world process or system over time. The act of simulating something first requires that a model be developed; this model represents the key characteristics or behaviors of the selected physical or abstract system or process. The model represents the system itself, whereas the simulation represents the operation of the system over time. II.

SIMULATION TYPES

Simulators either run as in an asynchronous mode, event triggered mode, or in synchronous mode, where events happen in parallel in fixed time slots [1]: A. Synchronous Simulation: The synchronous simulation is based on rounds. At the beginning of each round, the simulators increments the global time by one unit. Then, it moves the nodes according to their mobility models and updates the connections according to the connectivity model. After that, the framework iterates over the set of nodes and performs these steps for each node. B. Asynchronous Simulation: The asynchronous simulation is purely event based. The simulator holds a list of message events and timer events, which is sorted by the time when these events should happen (arrival of message, execution of timer-handler). The simulator repeatedly picks the most recent event and executes it. In general, the asynchronous simulation mode runs much faster than the synchronous mode. The main reason lies in the fact that the synchronous simulation mode loops over all nodes and performs for each node the set of fixed steps even if most of the nodes may not do any-thing at all. Whereas in

IJ ECCT | www.ijecct.org

176


asynchronous mode, only message and timer events are processed and no unnecessary cycles are wasted. III.

CATEGORIZATION OF SIMULATORS

In a research contribution WSN Simulators are categorized [2] as: A. Generic Network Simulators: Generic network simulators simulate systems with a focus on networking aspects. The user of the simulator typically writes the simulation application in a high level language different from the one used for the real sensor network. Since the focus of the simulation is on networking the simulator typically provides detailed simulation of the radio medium, but less detailed simulation of the nodes. B. Code Level Simulators: Code level simulators use the same code in simulation as in real sensor network nodes. The code is compiled for the machine that is running the simulator, typically a PC workstation that is magnitudes faster than the sensor node. Typically code level simulators are operating system specific since they need to replace driver code for the sensors and radio chips available on the node with driver code that instead have hooks into the simulator. C. Firmware Level Simulators: These simulators are based on emulation of the sensor nodes and the soft-ware that runs in the simulator is the actual firmware that can be deployed in the real sensor network. This approach gives the highest level of detail in the simulation and enables accurate execution statistics. This type of simulation provides emulation of microprocessor, radio chip and other peripherals and simulation of radio medium. Due to the high level of detail provided by firmware level simulators, they are usually slower than code level or generic network simulators. D. Algorithm Level Simulators: Some simulators focus on the logic, data structure and presentation of the algorithms. For example, AlgoSensim analyzes specific algorithms in WSNs, e.g. localization, distributed routing, flooding, etc. Shawn is targeted to simulate the effect caused by a phenomenon, improve scalability and support free choice of the implementation model. Sinalgo offers a message passing view of the network, which captures well the view of actual net-work devices. E. Packet Level Simulators: Some simulators implement the Data Link and Physical Layers in a typical OSI network stack. The most popular and widely used network simulator NS-2 is not originally targeted to WSNs but IP networks. SensorSim is an extension to NS-2 which provides battery models, radio propagation models and sensor channel models. J-Sim adopts loosely-coupled, component-based programming model, and it supports real-

ISSN:2249-7838

time process-driven simulation. GloMoSim is designed using the parallel discrete-event simulation capability provided by PAR-SEC. F. Instruction Level Simulators: Some simulators model the CPU execution at the level of instructions or even cycles. They are often regarded as emulators. They compute the power of a particular sensor’s hardware platform in WSNs. TOSSIM simulates the TinyOS network stack at the bit level. Atemu is an emulator that can run nodes with distinct applications at the same time. IV.

LIMITATIONS

The challenge of developing, deploying, and debugging applications on the realistic environment will be unmet with simulations. Many of the current simulators are un-able to model many essential characteristics of the real world. Simulations are based on common simplified assumptions and these do not produce accurate results. The simulation results are only as good as the model and they are still only estimated or projected outcomes. Especially for wireless sensor networks simulation models do not capture the radio and sensor irregularity. In a research contribution some issues are arises that really influencing the simulation results when simulators are directly used: The first one is that there should be an impact on simulation results by operating system architecture on which simulator is installed and result would have been taken. The second one is that all of cases simulators use a simulated clock, which advances in constant increments of time. Constant increment of time is decided by time stamp of the earliest event. So we must replace simulation clock with real system clock. The third one is that all simulators has its own protocol stack in its core (kernel) called simulator protocol stack. There are several problems in order to use a simulator protocol stack as a real network protocol stack, such as most of the simulators have various redundant proto-cols at various levels of simulator protocol stack to sup-port other types of networks for example TCP/IP based networks, Wireless Mesh Networks, Mobile Ad hoc Networks etc. The simulator also includes different radio, mobility, and propagation models. So according to our view these unnecessary redundant components must be removed in order to use a simulator protocol stack as a real protocol stack for WSNs. V.

STEPS IN A SIMULATION STUDY

Simulation consists of several steps which are described here and illustrated in figure 1. A. Problem Formulation(Step 1): Every simulation study begins with a statement of the problem. If the statement is provided by those that have the problem (client), the simulation analyst must take extreme care to insure that the problem is clearly understood. If a problem statement is prepared by the simulation analyst, it is important that the client understand and agree with the formulation. It is suggested that a set of assumptions be prepared by the


177


simulation analyst and agreed to by the client. Even with all of these precautions, it is possible that the problem will need to be reformulated as the simulation study progresses. B.

Setting of objectives and overall project plan(Step 2): Another way to state this step is "prepare a proposal." This step should be accomplished regardless of location of the analyst and client, viz., as an external or internal consultant. The objectives indicate the questions that are to be answered by the simulation study. The project plan should include a statement of the various scenarios that will be investigated. The plans for the study should be indicated in terms of time that will be required, personnel that will be used, hardware and software requirements if the client wants to run the model and conduct the analysis, stages in the investigation, output at each stage, cost of the study and billing procedures, if any. C.

Model conceptualization(Step 3): The real-world system under investigation is abstracted by a conceptual model, a series of mathematical and logical relationships concerning the components and the structure of the system. It is recommended that modeling begin simply and that the model grow until a model of appropriate complexity has been developed. For example, consider the model of a manufacturing and material handling system. The basic model with the arrivals, queues and servers is constructed. Then, add the failures and shift schedules. Next, add the materialhandling capabilities. Finally, add the special features. Constructing an unduly complex model will add to the cost of the study and the time for its completion without increasing the quality of the output. Maintaining client involvement will enhance the quality of the resulting model and increase the client's confidence in its use. D. Data collection(Step 4): Shortly after the proposal is "accepted" a schedule of data requirements should be submitted to the client. In the best of circumstances, the client has been collecting the kind of data needed in the format required, and can submit these data to the simulation analyst in electronic format. Oftentimes, the client indicates that the required data are indeed available. However, when the data are delivered they are found to be quite different than anticipated. For example, in the simulation of an airlinereservation system, the simulation analyst was told "we have every bit of data that you want over the last five years." When the study commenced, the data delivered were the average "talk time" of the reservationist for each of the years. Individual values were needed, not summary measures. Model building and data collection are shown as contemporaneous in Figure 1. This is to indicate that the simulation analyst can readily construct the model while the data collection is progressing. E. Model translation(Step 5) The conceptual model constructed in Step 3 is coded into a computer recognizable form, an operational model.

ISSN:2249-7838

F. Verified? (Step 6): Verification concerns the operational model. Is it performing properly? Even with small textbook sized models, it is quite possible that they have verification difficulties. These models are orders of magnitude smaller than real models (say 50 lines of computer code versus 2,000 lines of computer code). It is highly advisable that verification take place as a continuing process. It is ill advised for the simulation analyst to wait until the entire model is complete to begin the verification process. Also, use of an interactive run controller, or debugger, is highly encouraged as an aid to the verification process. G. Validated? (Step 7): Validation is the determination that the conceptual model is an accurate representation of the real system. Can the model be substituted for the real system for the purposes of experimentation? If there is an existing system, call it the base system, then an ideal way to validate the model is to compare its output to that of the base system. Unfortunately, there is not always a base system. There are many methods for performing validation. H. Experimental design(Step 8): For each scenario that is to be simulated, decisions need to be made concerning the length of the simulation run, the number of runs (also called replications), and the manner of initialization, as required. I.

Production runs and analysis(Step 9): Production runs, and their subsequent analysis, are used to estimate measures of performance for the scenarios that are being simulated. J.

More runs? (Step 10): Based on the analysis of runs that have been completed, the simulation analyst determines if additional runs are needed and if any additional scenarios need to be simulated. K. Documentation and Reporting(Step 11): Documentation is necessary for numerous reasons. If the simulation model is going to be used again by the same or different analysts, it may be necessary to understand how the simulation model operates. This will enable confidence in the simulation model so that the client can make decisions based on the analysis. Also, if the model is to be modified, this can be greatly facilitated by adequate documentation. The result of all the analysis should be reported clearly and concisely. This will enable the client to review the final formulation, the alternatives that were addressed, the criterion by which the alternative systems were compared, the results of the experiments, and analyst recommendations, if any. L.

Implementation(Step 12):s The simulation analyst acts as a reporter rather than an advocate. The report prepared in step 11 stands on its merits,


178


and is just additional information that the client uses to make a decision. If the client has been involved throughout the study period, and the simulation analyst has followed all of the steps rigorously, then the likelihood of a successful implementation is increased. VI.

DESIGN OF SENSOR NETWORK SIMULATOR

The design of a Wireless Sensor Network (WSN) is a very application-specific task, especially because of the peculiarity of the considered deployment environment. Generic reliable predictive models for data correlation or radio propagation are seldom available. A thorough preliminary test phase is thus necessary, either by means of specifically crafted test beds, or via reliable simulations. WSN applications must be tested on a large scale, and under complex and varying conditions in order to capture a sufficiently wide range of interactions, both among nodes, and with the environment. A WSN simulator consists of various modules namely events, medium, environment, node, transceiver, protocols, and applications. Each category is represented by an interface that defines its methods and events generated and consumed. 1) Event Event is an abstract base class that provides basic functionality for all events. It contains the time at which an event should work, and provides methods to: compare events based on their fire times, determine whether events are equal, print themselves to a string, and an abstract method to fire the event. 2) Medium Medium models the wireless medium. It allows nodes to broadcast signals, and is responsible for informing nodes of signals that affect it. In order to do this, Medium must be informed of the presence of every node, and any changes in position or radio properties such as transmitter power or receiver sensitivity. Medium has the properties of bandwidth and wavelength of the medium modeled and a reference to a propagation model that is given to it at the time of construction. The propagation model provides the strength at a particular receiver from a signal transmitted by a given transmitter. 3) Environment The Environment module is similar to Medium module. The difference is that the implementation of Environment has properties that relate to the physical phenomenon modeled. Environment also has a propagation model that models the propagation of the physical phenomena modeled. Physical phenomena of interest in sensor networks include: temperature, light, humidity, magnetic field, sound, optical, chemical presence. 4) Node It represents a single node in a wireless sensor network. As such, it serves as a container for all of the components, both hardware and software, in a node. These components should be included: processor, transceiver, sensors, actuators, energy source (such as a battery), network protocols, and applications.

ISSN:2249-7838

In addition each node has the properties of location and identification. 5) Transceiver Transceiver models the hardware transceiver on each sensor node. It models the transceiver states (i.e. sleep, standby, receive, and transmit), and their associated behavior and power consumption. Transceiver consumes events informing it of the beginning and ending of every signal it receives. It sums active signals to maintain the interference. Transceiver generates events for the beginning and ending of every signal it transmits. These events are all exchanged with an instance of the Medium module. 6) Physical Protocol The Physical protocol is the lowest layer in a network stack. It is often implemented in the transceiver hardware. The Physical layer provides services for: changing the state of the transceiver, carrier sensing, sending and receiving packets, received energy detection on received packets, changing channels on physical layers that support multiple channels. 7) MAC Protocol The MAC protocol is the next layer in a network stack. It is usually implemented in software running on the node’s processor. The MAC layer provides services for: changing the state of the MAC layer (i.e. low power mode), setting and getting protocol parameters, sending and receiving packets, etc. A WSN simulator usually offers implementations for several sensor network MAC protocols. 8) Routing Protocol The Routing protocol resides above the MAC protocol and provides services for routing messages over multiple hops between nodes that cannot communicate directly. 9) Application Layer The Application layer resides at the top of the network stack. It interfaces with the lower layers in the network stack as well as the sensors and actuators to implement a wireless sensor network application. B. WSN simulator should also have the following capabilities: 1) Reusability and availability Simulation is used to test novel techniques in realistic and controlled scenarios. Researchers are usually interested in comparing the performance of a new technique against existing proposals [3]. 2) Performance and scalability Performance and scalability is a major concern when facing WSN simulation. The former is usually bounded to the programming language effectiveness. The latter is constrained to the memory, processor and logs storage size requirements [4]. 3) Support for rich-semantics scripting languages to define experiments and process results


179


The vast amount of variables involved in the definition of a WSN experiment requires the use of specific input scripting languages, with high-level semantics. Additionally, it is likely that large quantities of output data will also be generated through many repslicas of the experiments [5]. Therefore, a suitable output scripting language, which helps to obtain the results from the experiments quickly and precisely is desirable. 4) Graphical, debug and trace support. Graphical support for simulations is interesting in three aspects: (a) As a debugging aid. The primary and more practical way to quickly detect a bad behavior is to “watch” and follow the execution of a simulation. The key features that a graphical interface should support are: Capability of inspection of modules, variables and event queues at real time, together with “step-by-step” and “run-until” execution possibilities. These features make graphical interfaces a very powerful debugging tool. Note that the key is the ability to interact with the simulation. (b) As a visual modeling and composition tool. This feature usually facilitates and speeds the design of small experiments or the composition of basic modules. However, for large scale simulations, it is not very practical. (c) Finally, it allows quick visualization of results without a post-processing application. VII. WSN SIMULATION SOFTWARES In this section some common general purpose simulators that are extensively used in simulating applications based on wireless sensor networks are discussed and their main features are studied in detail. A. NS-2 [7] : Discrete event simulator developed in C++. NS-2 is one of the most popular non-specific network simulators, and supports a wide range of protocols in all layers. It uses OTcl [8] as configuration and script interface. NS-2 is the paradigm of reusability. It provides the most complete support of communication protocol models, among non-commercial packages. Regarding WSN, NS-2 includes ad-hoc and WSN specific protocols such as directed diffusion [9] or SMAC [10]. Also, several projects intend to provide WSN support to NS-2 such as SensorSim and NRL [11]. Both are extensions of NS- 2 to support WSN modeling. However, SensorSim seems to be no longer available at [12]. NS-2 can comfortably model wired network topologies up to 1,000 nodes or above with some optimizations. This experiment size can be kept for wireless topologies using some new optimizations [13]. A disadvantage of NS-2 is that it provides poor graphical support, via Nam. This application just reproduces a NS-2 trace. NS-2 has been an essential testing tool for network research and, so, one could expect that the new conventional protocols will be added to future releases.

ISSN:2249-7838

Figure 1. Steps in Simulation


180


However, new proposals for WSN are increasingly being tested in specific tools, e.g. TOSSIM or EmTOS because of the advantage of native sensor code simulation and the specific design of these tools for WSN. Therefore, it is unclear the availability of new WSN proposals for next releases of NS-2. This problem may be even worse for less used Frameworks B. OMNET++ [14]: Modular discrete event simulator implemented in C++. Getting started with it is quite simple, due to its clean design. OMNET++ also provides a powerful GUI library for animation and tracing and debugging support. Its major drawback is the lack of available protocols in its library, compared to other simulators. However, OMNET++ is becoming a popular tool and its lack of models is being cut down by recent contributions. For instance, a mobility framework has recently been released for OMNET++ [15], and it can be used as a starting point for WSN modeling. Additionally, several new proposals for localization and MAC protocols for WSN have been developed with OMNET++, under the Consensus project [16], and the software is publicly available. Nevertheless, most of the available models have been developed by independent research groups and do not share a common interface, what makes difficult to combine them. As an example, not even the localization and MAC protocols developed in the Consensus project are compatible. C. J-Sim [17] : A component-based simulation environment developed entirely in Java. It provides real-time processbased simulation. The main benefit of J-sim is its considerable list of supported protocols, including a WSN simulation framework with a very detailed model of WSNs, and a implementation of localization, routing and data diffusion WSN algorithms. J-sim models are easily reusable and interchangeable offering the maximum flexibility. Additionally, it provides a GUI library for animation, tracing and debugging support and a script interface, named Jacl [18]. J-Sim claims to scale to a similar number of wireless nodes than NS-2 (around 500) with two orders of magnitude better memory consumption but a 41% worse execution time . D. GloMoSim [19] : Simulation environment for wireless networks built with Parsec. Parsec [20] is a simulation language derived from C, that adds semantics for creating simulation entities and message communication on a variety of parallel architectures. Taking advantage of parallelization, it has been shown to scale to 10,000 nodes [21]. Several proposals for WSN protocols have been tested with it. Recently, a development kit for WSN has been released, sQualnet [22]. E. SSFNet [23] : Set of Java network models built over the Scalable Simulation Framework (SSF). SSF is a specification of a common API for simulation, that assures portability between

ISSN:2249-7838

compliant simulators. There are multiple Java and C++ implementations of SSF. DartmouthSSF (DaSSF) [24], for instance, is a C++ implementation of SSF oriented to (parallel) simulation of very large scale communication networks. F. EmStar/EmSim/EmTOS [25] [26] : EmStar is a software framework to develop WSN applications on special platforms called microservers: Ad-hoc systems with better hardware than a conventional sensor. The EmStar environment contains a Linux microkernel extension, libraries, services and tools. The most important tools are: EmSim: A simulator of the microservers environment. In EmSim every simulated node runs an EmStar stack, and is connected through a simulated radio channel model. It is not a discrete event but a time-driven simulator, that is, there is no virtual clock. EmCee: An interface to real low-power radios, instead of a simulated radio model, obtaining radio emulation. EmStar source code (note that this code can be in any language) is used in the simulations. VIII.

CONCLUSION

The goal of this paper is to provide a comprehensive study on various aspects of simulation that can act like a base for the users in understanding the basics of simulations and its significance in real world scenarios.This paper will help the users to determine and select the simulators to be used in different situations based on the requirement of the applications. REFERENCES Distributed Computing Group, “Sinalgo-Simulator for Network Algorithms http://disco.ethz.ch/projects/sinalgo/tutorial/tuti.html. [2] J. Eriksson, “Detailed Simulation of Heterogeneous Wireless Sensor Networks,” Dissertation for Licentiate of Philosophy in Computer Science, Uppsala University, Sweden, April 2009 [3] John Heidemann, Kevin Mills, Sri Kumar, Expanding Confidence in Network Simulations. [4] E. Egea-López, J. Vales-Alonso, A. S. Martínez-Sala, P. Pavón-Mariño, J. García-Haro, Simulation Tools for Wireless Sensor Networks [5] Mekni, M. Moulin, A Survey on Sensor Webs Simulation Tools. [6] WeiChung,Hu MingLun, Lee TzungShian, Tsai Hewijin, Christine Jiau, A GUI Simulation Model in Supporting Embedded Software Design [7] The Network Simulator, NS–2 [Online]. Available: http://www.isi.edu/nsnam/ns/ [8] MIT Object Tcl. [Online]. Available: http://bmrc.berkeley.edu/research/cmt/cmtdoc/otcl [9] C. Intanagonwiwat, R. Govidan, D. Estrin, J. Heidemann, F. Silva, “Directed diffusion for wireless sensor networking.” IEEE/ACM Transactions on Networking, vol. 11, issue 1, pp. 2–16, February 2003. [10] W. Ye, J. Heidemann, D. Estrin, “Medium Access Control with Coordinated, Adaptive Sleeping for Wireless Sensor Networks.” ACM/IEEE Transactions on Networking, vol. 12, pp. 493–506, 2004. [11] NRL’s Sensor Network Extension to NS-2 [Online]. Available: http://nrlsensorsim.pf.itd.nrl.navy.mil/ [12] SensorSim: A simulation framework for sensor networks. [Online]. Available: http://nesl.ee.ucla.edu/projects/sensorsim/ [1]


181

International Journal of Electronics Communication and Computer Technology (IJECCT) Volume 2 Issue 4 (July 2012) [13] V. Naoumov, T. Gross, “Simulation of Large Ad Hoc Networks.” In Proc. ACM Modeling, Analysis and Simulation of Wireles and Mobile Systems (MSWiM 2003), San Diego, CA, pp. 50–57, 2003. [14] OMNET++ discrete event simulator. [Online]. Available: http://www.omnetpp.org [15] Mobility Framework for OMNET++. [Online]. Available: http://mobility-fw.sourceforge.net [16] Consensus: Collaborative Sensor Networks [Online]. Available: http://www.consensus.tudelft.nl [17] J-Sim [Online]. Available: http://www.j-sim.org [18] Jacl, Java implementation of Tcl8.x. [Online]. Available: http://www.tcl.tk/software/java [19] Global Mobile Information Systems Simulation Library (GloMoSim). [Online]. Available: http://pcl.cs.ucla.edu/projects/glomosim/ [20] PARSEC: Parallel Simulation Environment for Complex Systems. [Online]. Available: http://pcl.cs.ucla.edu/projects/parsec/ [21] M. Takai, R. Bagrodia, K. Tang, M. Gerla, “Efficient Wireless Networks Simulations with Detailed Propagations Models.” Kluwer Wireless Networks, 7, pp. 297– 305, 2001. [22] sQualnet: A Scalable Simulation Framework for Sensor Networks. [Online]. Available: htpp://nesl.ee.ucla.edu/projects/squalnet/ [23] Scalable Simulation Framework (SSF). [Online]. Available: http://www.ssfnet.org [24] Dartmouth SSF (SSF). [Online] [25] L. Girod, J. Elson, A. Cerpa, T. Stathopoulos, N. Ramanathan, D. Estrin, “EmStar: A software Environment for Developing and Deploying Wireless Sensor Networks.” In Proc. USENIX 2004, Boston, MA, pp. 283–296, 2004. [26] L. Girod, T. Stathopoulos, N. Ramanathan, J. Elson, D. Estrin, E. Osterweil, T. Schoellhammer, “A System for Simulation, Emulation and Deployment of Heterogeneous Sensor Networks.” In Proc. 2nd ACM Int. Conf. Embedded Networked Sensor Systems (SenSys), Baltimore, MD, pp. 201–213, 2004.

ISSN:2249-7838


182