The SWANS software is organized as independent software components that can
be composed to form complete wireless network or sensor network simulations,
as shown in Figure 1. Its capabilities are similar to ns2
[5] and GloMoSim [10], two popular wireless network
simulators. There are components that implement different types of
applications; networking, routing and media access protocols; radio
transmission, reception and noise models; signal propagation and fading
models; and node mobility models. Instances of each component type are shown
italicized in the figure.

Figure 1:
The SWANS simulator consists of event-driven components that can
be configured and composed to form the desired wireless network
simulation. Different classes of components are shown in a typical
arrangement together with specific instances of component implementations
in italics.

Notably, the development of SWANS has been relatively painless. Since JiST
inter-entity message creation and delivery is implicit, as well as message
garbage collection and typing, the code is compact and intuitive. Components
in JiST consume less than half of the code (in uncommented line counts) of
comparable components in GloMoSim, which are already smaller than their
counterpart implementations in ns2.

Every SWANS component is encapsulated as a JiST entity: it stores it own
local state and interacts with other components via exposed event-based
interfaces. SWANS contains components for constructing a node stack, as well
components for a variety of mobility models and field configurations. This
pattern simplifies simulation development by reducing the problem to creating
relatively small, event-driven components. It also explicitly partitions the
simulation state and the degree of inter-dependence between components, unlike
the design of ns2 and GloMoSim. It also allows components to be readily
interchanged with suitable alternate implementations of the common interfaces
and for each simulated node to be independently configured. Finally, it also
confines the simulation communication pattern. For example, Application or Routing components of different nodes cannot
communicate directly. They can only pass messages along their own node stacks.

Consequently, the elements of the simulated node stack above the Radio
layer become trivially parallelizable, and may be distributed with low
synchronization cost. In contrast, different Radios do contend (in
simulation time) over the shared Field entity and raise the
synchronization cost of a concurrent simulation execution. To reduce this
contention in a distributed simulation, the simulated field may be partitioned
into non-overlapping, cooperating Field entities along a grid.

It is important to note that, in JiST, communication among entities is very
efficient. The design incurs no serialization, copy, or context-switching cost
among co-located entities, since the Java objects contained within events are
passed along by reference via the simulation time kernel. Simulated network
packets are actually a chain of nested objects that mimic the chain of packet
headers added by the network stack. Moreover, since the packets are timeless
by design, a single broadcasted packet can be safely shared among all the
receiving nodes and the very same object sent by an Application entity
on one node will be received at the Application entity of another
node. Similarly, if we use TCP in our node stack, then the same object will be
referenced in the sending node's TCP retransmit buffer. This design conserves
memory, which in turn allows for the simulation of larger network models.

Dynamically created objects such as packets can traverse many different
control paths within the simulator and can have highly variable lifetimes. The
accounting for when to free unused packets is handled entirely by the garbage
collector. This not only simplifies the memory management protocol, but also
eliminates a common source of memory leaks that can accumulate over long
simulation runs.

The partitioning of node functionality into individual, fine-grained entities
provides an additional degree of flexibility for distributed simulations. The
entities can be vertically aggregated, as in GloMoSim, which allows
communication along a network stack within a node to occur more
efficiently. However, the entities can also be horizontally aggregated
to allow communication across nodes to occur more efficiently. In JiST,
this reconfiguration can happen without any change to the entities themselves.
The distribution of entities across physical hosts running the simulation can
be changed dynamically in response to simulation communication patterns and it
does not need to be homogeneous.