Sensors Network Simulators Sensing Networking Qing Fang 10/14/05 Computation
This Talk Not on how to run various network simulators Instead What differentiates various simulators Brief structures of the major simulators and their design considerations Goal: understand what simulations can really achieve and which simulator to choose for your purpose. Pointers to how to get started.
Outline Network simulation 1-2-3 NS-2 TOSSIM NS-2 vs. TOSSIM
When a network simulator is needed? User System Application Application Network Stack Threads Transport Network Address Space Files Data Link Physical Layer Drivers If it s necessary to include the networking behaviors (multiple access control, flow control, etc.) to make your point. And You care about performance metrics, such as: packet loss, delay, etc. in an eventdriven distributed environment. Routers
Developing Protocols The distributed world view Event-driven programming Use of timers
Choosing a Simulator Accuracy expressiveness Scalability simple, only keep minimal fidelity to observe critical phenomena How much learning involved vs. how much time you have
Simulators for Sensornet Research NS-2: the de facto general network simulator (Multiple institutions funded by DARPAR, NSF). TOSSIM: the TinyOS mote simulator (Berkeley). SensorSim: built on top of ns-2 for WINS platform. No longer supported (UCLA). EmStar: a flexible environment for transitioning between simulation and deployment for ipaq-class sensors (UCLA) TOSSF: limited documentation, looks promising (Dartmouth)
NS-2 vs. TOSSIM 1. The predominant network simulator 2. Simulates networks at the packet level 3. Allows a wide range of heterogeneous network configurations. Built-in propagation models. 4. Simulates networking stacks from the physical layer all the way to the transport layer 1. A TinyOS simulator that provides a network model 2. Simulates at the bit level 3. External radio models 4. Component oriented modeling after TinyOS 5. Better GUI
NS-2 Wired and Wireless Size : (Current release adds around 10%) 100K lines of C++ 70K lines of OTcl 30K lines of test suites 20K lines of documentation
NS Architecture Completely follow the OSF layered architecture Object-oriented (C++, OTcl) Scalability + Extensibility Control/primitive separation Split Otcl/C++ object Modular approach Fine-grained object composition High reusability
C++ and Otcl Separation C++ for computation OTcl for control (programmable simulator) Periodic or triggered action Compromise between composibility and speed Learning and debugging
OTcl and C++: The Duality
NS2 Disadvantages Does not work well for large topologies(more than 300 nodes), but there is a work around for that when nodes are immobile Large memory footprint 100 nodes 23MB 1000 nodes 412 MB
Don t worry about Otcl. Its easy.. To Use NS2 Forget about Nam traces (slow, ugly, hard to see useful info anyway). Write your own visualization program if you want to impress others. The online documentation is quite resourceful. Get started as soon as possible. Adding new protocols by simply adding new subclasses of agent at the appropriate places. Some internal changes might be necessary.
Basics to Learn Write the configuration file in Otcl (plenty of examples on-line). How files are structured (read the manual and poke around in the ns directory). How to add a protocol: the agent class the packet.h file the void recv ( Packet * pkt, Handler* h) function in C++ the Otcl interface (the int command(int argc, const char*const* argc)) to its C++ function
My Own Experience with NS-2 Layered structure, easy to understand its logic flows Once understand how they interact and how the files are structured (a steep initial learning curve), easy to hack. The built-in routing algorithms could be buggy.
Goals of TOSSIM Scalability: able to handle large networks Completeness: capture complete system behavior Fidelity: capture behavior at a fine-grain Bridging: the gap between algorithms and implementation
The Radio Model Radio models external to TOSSIM Models network as a directed graph of bit error probabilities, which can be changed at runtime. Allows asymmetric links.
TOS Application = Graph of Components application Route map router sensor appln Active Messages bit byte packet Radio Packet Radio byte RFM Serial Packet UART Temp ADC photo clocks SW HW Example: ad hoc, multi-hop routing of photo sensor readings Graph of cooperating state machines on shared stack
A Multihop Routing Example
TOSSIM Architecture
Communication Services Allows PC applications (TCP/IP etc) to drive, monitor, debug simulation. TinyViz a java-based GUI allowing simulations to be visualized, analyzed and controlled. TinyViz engine manage the event/command interface between user plugins to TOSSIM.
A TinyViz Example Setting ADC values
Programming TOSSIM Write your own component (or modify the existing ones), assemble your application. Write your own plugins (states you want to observe or control) if needed. Comparatively easy to learn if you are not new to event-driven programming.
Things Can Make TOSSIM More Appealing CPU modeling : run-instantly model Energy modeling Supporting heterogeneous platforms
TOSSIM Summary The same code can be used both for simulation and testbed deployment. Fine-grained simulation, scalable to thousands of nodes (claimed). Does not address energy profiling. Applicable only on TinyOS platform.
NS-2 vs. TOSSIM - A Recap 1. The predominant network simulator 2. Simulates networks at the packet level 3. Allows a wide range of heterogeneous network configurations. Built-in propagation models. 4. Simulates networking stacks from the physical layer all the way to the transport layer 1. A TinyOS simulator that provides a network model 2. Simulates at the bit level 3. External radio models 4. Component oriented modeling after TinyOS 5. Better GUI 6. Comparatively easier to learn
After All Why do we need simulations in the first place? Controlled, Reproducible testing environment Cost-effective, alternative to real deployment Means to explore and improve design space while factoring into uncertainties (system, environment, etc.) So, be clear what you want, i.e. at what level of details you want your simulation to be. Then, design sensible scenarios and be specific in reporting how you made comparisons.
More Detailed Questions? Talk to the TA
The End
Components Modules provide code that implements one or more interfaces and internal behavior Configurations link together components to yield new component Interface logically related set of commands and events StdControl.nc Clock.nc interface StdControl { command result_t init(); } command result_t start(); command result_t stop(); interface Clock { command result_t setrate(char interval, char scale); event result_t fire(); }