Ben L. Titzer, Daniel K. Lee, Jens Palsberg. "Avrora: Scalable Sensor Network Simulation With Precise Timing," Proceedings of IPSN'05, Fourth International Conference on Information Processing in Sensor Networks, 2005. [ summary >> ]
P. Levis, N. Lee, M. Welsh, and D. Culler. "TOSSIM: Accurate and scalable simulation of entire TinyOS applications," in Proceedings of the First ACM Conference on Embedded Networked Sensor Systems (SenSys) 2003, Nov. 2003. [ summary >> ]
V. Shnayder, M. Hempstead, B. Chen, G. W. Allen, and M. Welsh. "Simulating the power consumption of large-scale sensor network applications," in Proceedings of the 2nd International Conference on Embedded Networked Sensor Systems (SenSys 2004). [ summary >> ]
TOSSIM: Accurate and Scalable Simulation of Entire TinyOS Applications
TOSSIM is an event driven simulator for Mica2 motes running TinyOS.
TOSSIM's goals include: (1) Using algorithms similar to algorithms that will run on the actual harware so that the actual implementations can be studied and the code doesn't have to be written twice. (2) Simulating the entire network, both the operating system and network stack including network errors. Some other simulators abstract away a lot of aspects of a network that actually ought to be simulated. The paper argues that because sensor networking is a fairly new technology, the best level of abstraction is not yet known.
TOSSIM works with compiled TinyOS applications - The simulator runs the same code as the hardware except for a few parts (ADC, clock, EEPROM, etc). This feature was made available by modifying the ncc (nesC) compiler so that TinyOS programs can be compiled to run in TOSSIM by using a command-line option.
TOSSIM simulates the network stack at the TinyOS component level. They argue that simulating the network stack at low-level would limit scalability. The data link layer of the network stack uses the CSMA protocol and this is accuratly simulated. Packet loss (CRC failure) is also modeled using data collected from a real 26 node network.
Misc: Each node has an event queue that process events and simulated hardware interupts (like Avrora). The clock cycles (timer) runs at 4MHz, the same rate as the Mica2 mote. TOSSIM allows you choose what level of detail to simulate the radio - 'simple' vs. 'static'.
Simulating the Power Consumption of Large-Scale Sensor Networks
PowerTOSSIM is a wireless sensor network simulator that can estimate power consumption of Mica2 sensors running TinyOS. Other simulators either do not include this function, do not perform it completly, or model it in so much detail that results in making the simulator not scalable to a large number of nodes.
The paper compares and discusses the features of PowerTOSSIM with other simulators such as ns2, TOSSIM, and ATEMU. Some of the differences include: (1) TOSSIM simulates power consumption. (2) Some other simulators model one node at a time. PowerTOSSIM can simulate multiple nodes. (3) In contrast to ATEMU and ns2, PowerTOSSIM "runs applications as a native executable and does not directly simuate each node's CPU at the instruction level", which allows for greater scalability. Other sims model too many details which slows the simulation with large numbers of nodes.
PowerTOSSIM estimates power consumption by using a "power model" and "basic-block-level profiling". PowerTOSSIM's power model is based on real figures. To measure the power used by the CPU, radio, EEPROM, ADC they tested each device individually. The CPU runs in different states that consume different amounts of power. The 'active' state of the CPU uses 8 mA and 'standby', 'power-down', and 'power-save' use a lot less. The radio consumes from 3.7 mA to 21.5 mA. Since the radio is always listening it consumes a lot of power compared to the other devices. The power used by the ADC is included in the CPU measurements and in general does not consume a lot of power.
To estimate power usage these values are used in conjuction with the state transition messages logged by PowerState, a TinyOS software module, during simulation whenever a device on a node changes its state.
"Block profiling" is the method used to measure power consumed by the CPU. As blocks of code are executed they are mapped to the coresponding assembly language instructions, and since the number of clock cycles per instruction is known, this data can be used to count the total number of CPU cycles used during the execution of the simulation.
Avrora: Scalable Sensor Network Simulation with Precise Timing
Avrora is a "cycle accurate instruction level sensor network simulator which scales up to 10,000 nodes". Avrora is open-source and written in Java. The source code can be downloaded and contains some examples on getting started.
The paper explains the advantages of creating and using simulators and wireless sensor simulators in general, describes the tradeoffs that should be considered in building simulators - accuracy vs. scalability, talks about the features of different wireless sensor network simulators such as SensorSim, SWAN, SENS, TOSSIM, and ATEMU, and then describes the design of Avrora in detail.
Trade-offs: Simulators that "[run] models of the nodes rather than simulating an actual software implementation" tend to be more scalable but less accurate. Simulators that do not use much modeling are more accurate but less scalable. Some simulators, like TOSSIM, use both methods. The goal of Avrora is also balancing accuracy and scalability and it runs actual applications, not models of the applications.
A lot of the paper deals with issues of synchronization. In ATEMU each node has a counter (timer) that represents the clock cycle. Checking whether an event has occured and triggering an interupt if necessary happens every 1024 cycles. In contrast, Avrora uses threads - each node corresponds to one thread and synchronization is not needed as much.
Another aspect of Avrora is the event queue. An event queue is used because nodes spend a lot of time in the sleep state and no instructions are executed. Nodes can be woken up by an event caused either by the software or something in the environment. When an event occurs they are added to the queue of the node and then processed. If the event causes an interupt the node will become active. Simulating nodes' sleeping improves the execution time of the simulator.