Outline of Presentation TOSSIM : Introduction Need for - PDF document

Outline of Presentation TOSSIM : • Introduction – Need for simulating sensor networks Accurate and Scalable Simulation – Requirements for simulating sensor networks of Entire TinyOS Applications • TOSSIM – Overview Philip Lewis Nelson Lee Matt Welsh David Culler – Architecture – Functions and Features – Evaluation Presented by – Future Work Anthony Fynn • Conclusion Introduction Introduction • Requirements for a TinyOS simulator • Need for simulator – Scalability – Study an entire system in a controlled environment • Simulator must support network of very large numbers of nodes in a wide range of – Explore system configuration that are hard to configurations physically construct – Completeness – Observe interactions that are difficult to – Fidelity capture in a live system – Bridging Introduction Introduction • Requirements for a TinyOS simulator • Requirements for a TinyOS simulator – Scalability – Scalability – Completeness – Completeness • Simulator must accurately capture all system – Fidelity interactions • Simulator must capture behavior of the network at – Fidelity a fine grain for evaluation and validation of code – Bridging – Bridging 1

Introduction Introduction • Prior simulators for sensor networks • Requirements for a TinyOS simulator – ns-2 – Scalability • A general network simulator – Completeness • Does not meet the requirements of simulating an – Fidelity application such as TinyOS – Bridging – EmStar • Simulate sensor network applications running on • Simulator must bridge the gap between algorithm Linux and implementation to allow developers to test – TOSSF code • Simulates TinyOS code for a different simulation framework. Not evaluated • Authors claim techniques borrowed from TOSSIM TinyOS Recap TOSSIM - Overview • A TinyOS program is a graph of components • Like TinyOS applications, TOSSIM is component based and event-driven – Components are mainly hardware resources such as ADC, sensors, computational entities • Low-level components may be re- – Components have 3 computational implemented to capture mote behavior at abstractions: commands, events and tasks a fine grain • TinyOS stack uses three network sampling • Simulation is based on a virtual clock rates – 40Kbps, 20Kbps and 10Kbps TOSSIM - Overview TOSSIM - Architecture • Uses a directed graph to represent a network – Each vertex represents a node • Parts – Each edge has a bit error probability – Compiling component graphs into simulation – Abstraction can capture most conditions infrastructure – Discrete event queue E.g. – Hardware abstraction of a a component 0 – Radio and ADC models b c b c – Communication services Perfect transmission between a Hidden terminal problem and b 2

TOSSIM – Event Simulation TOSSIM – Network Simulation • Receiver radio clock need to be adjusted to synchronize with • Simulator event cycle sender signal • Adjustments to radio bit rates are made by changing the period between radio clock events • Network stack is simulated at bit level TinyOS Event Interrupts task queue Interrupts Interrupt handler() simulator TinyOS Command() event queue Tasks Tasks TinyOS Event TOSSIM - Evaluation TOSSIM - Features • Fidelity • Single compiler support for simulation and – Radio noise hardware • Radio loss graphs generated physical topologies – Added a compiler option to the nesC Compiler based on empirical data from real-world network to compile an application for simulation • Conclusion: Shows that TOSSIM’s bit-error instead of mote hardware mechanism allows for implementation of complex • Visualization tool ( TinyViz ) models – Allows simulations to be visualized, controlled and analyzed through a GUI – Allows for plugins for users to interact with simulation TOSSIM - Evaluation TOSSIM - Evaluation • Fidelity • Fidelity – Packet-level interactions – Subtle race conditions • Investigated effects of transmission rate and • Race condition that occurred in the Media Access network density on reliability of packet Control component was uncovered transmission • Conclusion: Condition would not have been • Simulated a TinyOS application at three network uncovered if TOSSIM did not have the ability to densities simulate at a very fine granularity • Conclusion: The denser the network and higher the transmission rate resulted in more packet loss respectively 3

TOSSIM - Evaluation TOSSIM - Evaluation • Completeness • Bridging – Surge – TOSSIM compiles directly from TinyOS code • Wide range of anomalous behavior uncovered – Simulation code is almost identical to code – Packet overflow due to interactions between running on hardware transmission policy and Active Messaging level – Users can transition between simulation and acknowledgements real-world network – TinyDb – Users can step through simulation code with • SQL-based interface to query sensor network • Reported that TOSSIM provided a useful traditional debuggers without disrupting mote environment for prototyping new features execution – Evaluation mainly based on one application TOSSIM - Evaluation TOSSIM – Future Work • Scalability • Researchers are exploring connecting – TOSSIM is scalable for large number of real-world motes to the TOSSIM nodes and more complex application networking model • Researchers are modifying TOSSIM so that multiple running copies can communicate through a network proxy • Energy consumption need to be captured • TOSSIM should be made less application specific Simulations of three application of varying complexities Conclusion • TOSSIM captures a good deal of a real- work sensor network running a TinyOS application • The effectiveness of TOSSIM cannot be generalized for all sensor networks • It seems authors evaluated sensor network simulation based on the capabilities TOSSIM 4