SensorSimII Internals

Contents:
        Introduction
        Compile/Run
        Overview
        Toplevel
        Node Object (Application, Network, Link Levels)
        Messages

More to come...

Introduction

WARNING: Information in these pages is just something quick to help provide some documentation for this project. It is nowhere near complete. This was thrown together in a rush, so please excuse this document's lack of clarity and spelling. If you have questions or problems, please email me (Craig Ulmer) at grimace@ee.gatech.edu.

SensorSimII is written in Java as a basic simulator for sensor networks. Right now SS2 is more of a framework for simulations than a general purpose simulator. This means that it is expected that users will write their own java code to get the simulator to simulate what they're interested in as opposed to a simulator that is programmed by scripts or user input. I intend to build more infrastructure to perform scripted simulations in the future, but there's still a lot of work to do. I started writing SensorSimII as a means of answering some of my own distributed computing questions. If you find that you can use it for your own work, feel free to adapt it as you need. This project is open source (if you can stand reading it), just please send me a pointer or copy of your work and reference me accordingly.

Compile/Run Info

I've been using Microsoft's Visual J++ v6.0 to build this project (MSVJ project files are included). In theory any of the standard java compilers should work, although you may need to make a Makefile since there may be some circular references in the code. Because of the variety of locations that the simulator was run, I've used the MSVJ++ packaging options to create a few forms of output. There are basically three types of output that are dumped out:

.class files: These are the most universal form of output. Using java.exe, you can run any of the .class files from the command line that contains a Main(). There are two main classes of interest:

jview frMain.class: This is the graphical version of the simulator. The graphical version maintains windows and can change simulator cores if the user wants to restart everything.
jview sensorSimCore.class: This is a console only version. By editing the main, you can get it to perform specific simulator actions. (This is where a script interpreter will fit in the future.)

.jar applet: The simulator can also be packaged to run as an applet. The goal here is to package the simulator in a way that it can be put on a web page. Building the jar file isn't automated right now, you just have to tar up all of the class files. I use a stub applet called sensorSimViewerApp that contains a button that launches the frMain class. You can load up the index.html file to run the applet or:

jview /a sensorSimViewerApp.class (or just appletviewer sensorSimViewerApp)

.exe file: MSVJ++ can package all class files together to make an all in one executable file for Windows x86 machines. Note that this isn't anything all that fancy, you still need to have the latest java virtual machine installed in order for this to work, and simulation isn't any faster than using jview.

When compiling, you should get a couple of warnings (from the sensorSimApp file) about certain calls being deprecated. These shouldn't be a problem, I just needed something quick and haven't gotten around to updating the calls to the new Java API.

SensorSimII Overview

You can divide work in SensorSimII into two areas: the simulator core and visualization tools. I've tried to keep these two items as separate as possible, simply to preserve the ability to run the simulator in a command line form. The bulk of this document will talk about the simulator core since that is the scientifically interesting part of this project.

The simulator core essentially manages an array of independent sensor nodes throughout time. Nodes are furnished only with information they can directly observe. It is assumed that nodes wake up at some point in time knowing nothing and must discover features of their environment in order to construct a useful sensor network. There is no global knowledge in these networks other than that which is a result of information dissemination protocols. The simulator steps through time with each node reacting to observed events.

Simulator Toplevel

There are a few objects used at the top level to control how the simulator functions. The main objects are:

Configuration Object: The configuration object (variable C) is used in practically all objects within the simulator as a means of storing global variables (e.g., the current simulation clock time) and configuration parameters used by the simulator. It also contains helper functions to redirect debug messages (to the console or the GUI).
Topology Object: A base topology object is used to store information about the physical distribution of sensor nodes. The base topology class contains methods for determining links in the topology based on proximity, pruning algorithms to find the maximum fully connected graph, load/store primitives for graphs, and drawing methods for GUIs. The topology object is used only during the initialization of the simulator.
Node Array: This array contains all of the Node Objects used in the simulation.

In initialization the simulator core examines the Configuration object to determine how the simulator should be constructed. A new topology object (such as a sphere or random graph) is created based on the configuration. The topology then determines neighbors based on proximity and creates a list of neighbor links. the simulator core creates the node array and feeds information from the topology object into the nodes (e.g., node 4's physical layer is told that any broadcast transmission will be observed by nodes 4,5, and 7). Each node is placed in an initial sleep state and given a time to wake up and start functioning.

After initialization, the simulator core walks through simulation time by calling specific methods of each node. A simulation clock is broken into the following operations:

cycleStart: This signifies a new clock phase. Any cycle-by-cycle statistical information should be adjusted (i.e. messages heard this cycle set to 0).
cycleDetermineActions: In this phase all nodes determine what exactly they're going to do this cycle. Information about what other nodes have decided to do is withheld so that two nodes can simultaneously decide to transmit to each other.
cyclePerformActions: The actions that nodes determined in the previous phase are carried out.
cycleUpdateClocks: Any post-cycle tallying information is computed (i.e., messages heard this cycle is stored).

Node objects must implement each of these methods for simulation. A node is also responsible for propagating each of these clock events to all objects in the node (e.g., the cycleStart() method in a node calls the cycleStart() method in all of the node's functional layer objects).

Node Object

The majority of the work for the simulation core is simulating how a node observes events and reacts. The challenge is building the node in a fashion that it is realistic while still being flexible enough to handle several styles of simulation. As depicted in figure 1, we decided to organize a node into three distinct components: Application level, Networking level, and Link level.

Figure 1: Node Components

Responsibilities for each object in the node are:

Application Level: This is the layer that holds all of the end-all scientific applications for the network. This can include distributed fusion algorithms, sampling correlation, and time/position synchronization. It is expected that nodes will run more than one application, and that applications are handled by a microprocessor.
Network Level: This object handles the node's routing algorithm. We envision that people would write different distributed algorithms at this level (such as DSR, AODV, etc.). This level would also be responsible for building the data collection trees in information dissemination protocols.
Link Level: This object is for the actual transmission from one node to another. Users can explicitly define MAC protocols here, or implement commercial chipsets such as Bluetooth or 802.11.

In the future I plan to add other objects for more rigorous use, including a sensor object (providing raw data to the node), a power management object, a memory management object, and an object for general faults.

In addition to these objects a node contains basic information: a unique ID number, a list of nodes that will observe the node's transmissions (neighbors_finite), cluster identification for the node, and a list of neighbors that the node is aware of.

Node: Application Level

The application supports the running of several concurrent high-level applications for the sensor node. As depicted in figure 2, these applications must share the use of the node's communication facilities. The Application object therefore allows only one application to inject a message during each cycle (if the NI can accept a new message) and polls applications in a round robin fashion. Messages that come from the NI have an application ID that allows messages to be sent to the necessary application.

Figure 2: Application Level Framework

Node: Network Level

The network layer is responsible for providing the node's perspective on routing in the sensor network. The network level therefore contains a few components: a state machine for handling routing updates, a route cache for storing state, and interfaces for both the application and link levels. The network layer can passively update its routing state by monitoring the packets that the link layer observes (i.e., if the link layer overhears a packet that is destined for a another node, the network layer can still make use of the source/destination information in the packet). Messages that the application layers inject check the network layer for routing information. For messages received by the link level that are using the node in a multi-hop scheme, the network level is consulted to determine how to forward the message.

Node: Link Level

The link level is designed to serve a number of simulation configurations and works under the simple abstraction of reliably transmitting data from one node's link level to another neighbor's link level. In the current simulator we use a basic MAC/Phys entity for the link level that allows users to design custom MAC and Physical protocols. The current MAC uses a basic RTS/CTS/DATA/ACK dialog for reliable delivery and can allow for unprotected broadcast transmissions. The physical layer provides carrier sensing back pressure to reduce collisions. The physical layer provides the actual communication among nodes in the simulator, assuming that messages (be it MAC or data) are broadcast to all neighbors within in fixed communication radius. We decided to use a link level abstraction (instead of a Link/Phys) due to the possibility that future simulations might use commercial chipsets such as Bluetooth or 802.11 that define both Link and Phys.

Messages

Communication messages in the simulator have there own class from which various message types are derived. Messages are constructed to be self contained, holding all information necessary for routing and receiver side decoding. Helper functions are available to make sure that messages have an appropriate associated byte length. Note that we've tried to make byte lengths somewhat realistic (i.e., ids are two bytes long since we expect there to be more than 256 nodes). The byte length may be used in both the physical level (to determine how long the transmission lasts) or at locations where the message may be buffered (to determine if enough buffer space is available).