CSM

SWAN – A Simulator for Wireless “Ad Hoc” Networks: 

SWAN – A Simulator for Wireless “Ad Hoc” Networks Luiz Felipe Perrone perrone@ists.dartmouth.edu Institute for Security Technology Studies Dartmouth College With Jason Liu, David Nicol and Michael Liljenstam

Wireless Ad-Hoc Networks: 

Wireless Ad-Hoc Networks Battery operated computing devices Communication happens via radio or laser beams Nodes are free to move Single or multihop Automagic configuration No need for infrastructure

An Application: Sensor networks: 

An Application: Sensor networks Intelligence, Surveillance, Emergency Response M M

Technology Challenges: 

Technology Challenges Medium Access Control (MAC): How do we coordinate multiple, autonomous entities access to a common portion of the communication spectrum?

Technology Challenges: 

Technology Challenges Routing: How do we set up routing services for a network with a potentially very large number of nodes?

Technology Challenges: 

Technology Challenges Security: How do we give this network “nice” properties such as availability, confidentiality, integrity, authentication and nonrepudiation?

Technology Challenges: 

Technology Challenges Power awareness: How do we do all this in a way so as to minimize power consumption at each node and maximize the network lifetime?

Who Needs Simulation?: 

Who Needs Simulation? We do!!! We have a complex system that defies mathematical analysis. This system has several components tightly inter-connected. Experiments in validation and verification will call for repeatability and controllability. Again, who needs simulation?

Wish List for an WAN Simulator: 

Wish List for an WAN Simulator Detail Completeness Performance Scalability

Related Work: 

Related Work CMU: Monarch Project http://www.monarch.cs.cmu.edu/cmu-ns.html detailed radio propagation models, complete implementations of MAC and routing algorithms, scenario generation, visualization tools, network emulation, etc. UCLA: SensorSim (pre-release stage) http://nesl.ee.ucla.edu/projects/sensorsim/ sensing channel and sensor models, battery models, lightweight protocol stacks for wireless microsensors, scenario generation, and hybrid simulation. Common major drawback: they are based on ns-2.

How We’re Making It Happen: 

How We’re Making It Happen We started out with the Scalable Simulation Framework (SSF) http://www.ssfnet.org SSF Entity container for state variables inChannel outChannel endpoints of communication links between entities Process entity’s state evolution Event messages between entities SSF is not a simulator: it’s a specification with bindings for Java and C++.

SSF Modeling: 

SSF Modeling Entity A state process Entity B state process outChannel inChannel outChannel inChannel Event Timeline A.alignto(B) Channels have an associated delay which is used by the kernel to determine lookahead for parallel simulation. Channels are mapped to one another. Obviously large models would be painful to construct with this mechanism alone: enter DML (Domain Modeling Language).

DML and Design Patterns: 

DML and Design Patterns SMARTDUST [ ID 1 xpos 0 ypos 0 battery 1000.000000 graph [ ProtocolSession [ name "app" use "app.sensor-session" inter_arrival_time 0.002400 packet_size 100 total_neighbors 1 neighbor 2] ProtocolSession [ name "net" use "net.aodv-session"] ProtocolSession [ name "mac" use "mac.mac-802-11-session“] ProtocolSession [ name "phy" use "phy.phy-802-11-session" attach 2] ] ] The model is described by a hierarchical list of key-attribute pairs. Each key is looked up in a database, a class is fetched, and the list of attributes is passed to the corresponding class constructor. The model is constructed from the DML specification.

SSFNET-like Architecture: 

SSFNET-like Architecture Our host descriptions were “borrowed” from the architecture of SSFNET http://www.ssfnet.org A ProtocolSession models a protocol layer (as in the ISO/OSI reference model). A ProtocolGraph is a list of ProtocolSessions and models the complete protocol stack in a host. Adjacent ProtocolSessions communicate by exchanging ProtocolMessages. Application Session Transport Session Network Session Link Session PHY Session Protocol Graph

The ProtocolSession API: 

ProtocolSession N-1 The ProtocolSession API ProtocolSession N+1 ProtocolSession N pop control push (pop) (push) A ProtocolSession is a class that defines three methods: pop, push and control. An element higher in the stack can send it messages invoking push. An element lower in the stack can send it messages invoking pop. Anything that is not related to the protocol models is communicated using control.

ProtocolMessage: 

ProtocolMessage Data Message Router+IP Header MAC Header PHY Header Radio Frame Application Network MAC PHY

The DaSSF Homebrew: 

The DaSSF Homebrew An SSF-compliant simulator: Fast threading mechanism, Efficient memory utilization, Portable: runs on sequential and parallel machines (shared and distributed memory); IRIX/Solaris/SunOS/Linux/OSF. http://www.cs.dartmouth.edu/research/DaSSF

The Architecture of SWAN: 

The Architecture of SWAN Physical Process Terrain Model OS Model (DaSSF Runtime Kernel) Protocol Graph Host model time memory run thread RF Channel Model read terrain features read terrain features

Where Things Get Complicated: 

Where Things Get Complicated Physical Process: How do we simulate different physical phenomena with accuracy and efficiency? RF Channel Model: The multiple access technique determines the difficulty of model construction. Besides, will it scale up? Level of detail: Less may be better. More abstraction can mean faster simulation with no significant loss of accuracy.

802.11 RF Channel Model: 

802.11 RF Channel Model R a b c d r If transmitter is close enough so that receiver is within carrier range, packets are accepted. Otherwise, they are thrown away. Cutoff  model scalability  efficient parallelization.

802.11 RF Channel Model (cont.): 

802.11 RF Channel Model (cont.) R a b c r Elapsed time between tx of messages k and (k-1) If message length is exponentially dist. with mean 1/l, then Channel busy-ness: model the number of “active” messages in the channel.

802.11 RF Channel Model (cont.): 

802.11 RF Channel Model (cont.) R a b c r + The general shape of the curve for CSMA + Some mathematical manipulation Probability that a message is lost at k The loss model is now very simple: at the receiver, throw a to determine if a message is to be successfully received or discarded (lost).

Milestones Reached: 

Milestones Reached Abstraction of the RF Channel Model for 802.11 implemented. Detailed model for 802.11 DCF ported from GloMoSim and used to validate our abstracted RF Channel Model. Proof of concept simulations with networks of chemical sensors powered by BBN WiroKit routers.

Current State: 

Current State SWAN: Is it available for the general public yet? We’re sorry to say it isn’t, not yet. Routing: In order to have a public distribution, we need public domain technology. Mobility: support is being added. Host models: under revision to support power consumption. A Berkeley TinyOS port is in the works. Security: Ultimately our goal is to develop/study layers for ad hoc networks.

A Call to Arms: 

A Call to Arms Rome wasn’t built in a day. SSFNET wasn’t built by one group alone. We can use a lot of help to turn the duckling into the SWAN it’s meant to be.