December 23, 2003
This tutorial is intended to describe our work in incorporating wireless sensor network simulation in J-Sim. Our work builds up on the autonomous component architecture (ACA) of J-Sim. The tutorial is organized as follows: Section 2 presents the simulation architecture overview; this includes the description of the different types of nodes that are found in a typical wireless sensor network. Section 3 lists the tasks that we completed. Section 4 describes, using block diagrams, the layers of the protocol stack of each type of node mentioned in Section 2. Each layer in the protocol stack is a component. Section 5 gives a detailed description of the ports and contracts that enable different layers to interact in the initiator-reactor mechanism that is a fundamental concept of J-Sim. Finally, Section 6 provides a sample script of a wireless sensor network simulation; the script shows how layer (component) binding is deferred until a complete system is actually being built.
In a typical wireless sensor network, sensors monitor a
specific environment (e.g., an airport, a battlefield, etc.) and upon detecting
a relevant stimulus (signal), sensors send reports to a sink (user) node. There
are different types of stimuli; for example, acoustic and seismic. Stimuli are
generated by target nodes. Hence, a wireless sensor network simulation
environment consists of three main types of nodes: sensor nodes, target nodes,
and sink (user) nodes. Target nodes generate signals (stimuli). Sensor nodes
detect the signals (stimuli) that are generated by a target and forward the
necessary data to the sink nodes. Finally, a sink node receives data collected
by sensors.
Since the nature of signal propagation between target nodes and sensor nodes is inherently different from that between sensor nodes and sink nodes, two different models for channels and protocol stacks are needed. Namely, a sensor node is equipped with (1) a sensor protocol stack, which enables it to capture signals generated by target nodes through a sensor channel, and (2) a wireless protocol stack, which enables it to send reports to the sink nodes through a wireless channel. This operation is illustrated in Figure 1. The combination of the sensor protocol stack and the wireless protocol stack is usually called the sensor function model [1]. A sensor node also has a power model that embodies the energy-producing components (e.g., battery) and the energy-consuming components (e.g., radio and CPU) that enables a sensor to fulfill the functions of the sensor function model. Figure 2 shows an internal view of the three types of nodes [2].
Figure 1: A typical wireless sensor network environment
Figure 2.a: Internal view of a sensor node (dashed line)
Figure 2.b: Internal view of a target node (dashed line)
Figure 2.c: Internal view of a user (sink) node (dashed line)
In order to incorporate wireless sensor network simulation
in J-Sim, we made a new package: drcl.inet.sensorsim. All of the implemented
classes described below are defined inside this new package:
This includes the implementation of the following classes:
TargetAgent:
implements a target node. This involves generating signals (stimuli) and passing
them to the lower layers in order to be transmitted over the sensor channel.
TargetPacket: implements the packet that represents the signal generated by a target node.
SensorMobilityModel:
a derived class of drcl.inet.mac.MobilityModel. Since the target nodes may move
(e.g., moving tanks), their mobility pattern, speed and location are handled by
SensorMobilityModel.
SensorNodePositionTracker: keeps track of the locations of all the nodes. This
location information is being reported by the SensorMobilityModel component of
each node to the SensorNodePositionTracker. A major function done by this class
is that it determines the sensor nodes that are within the transmission radius
of a target node, and hence, should receive a copy of the signal generated by
that target node.
SensorPhy: This
class plays two roles depending on whether an instance of it exists in the
protocol stack of a target node or a sensor node. If it is defined in the
protocol stack of a target node, its function is to receive a signal generated
by the TargetAgent, query the SensorMobilityModel component to get the most
up-to-date location of the target node, and forward the generated signal
(together with the location information) to the sensor channel component.
SensorPositionReportContract: defines the contract needed to define the
interface between SensorPhy and SensorMobilityModel and also between
SensorMobilityModel and SensorNodePositionTracker.
This includes the implementation of the following classes:
SensorChannel:
implements the sensor channel. The function of the sensor channel is that it
receives a signal (stimulus) from a target node, queries
SensorNodePositionTracker to get the list of sensor nodes that are within the
transmission radius of that target node, and hence, should receive a copy of the
signal generated by that target node. The sensor channel then sends a copy of
the generated signal to each sensor node that belongs to that list.
SensorNodeChannelContract:
defines the contract needed to define the interface between SensorChannel and
SensorPhy.
SensorNeighborQueryContract: defines the contract needed to define the interface
between SensorChannel and SensorNodePositionTracker.
This includes the implementation of the following classes:
SensorRadioPropagationModel: abstract base class for different types of signal
propagation models on the sensor channel.
SeismicProp:
derived class of SensorRadioPropagationModel. The major function of SeismicProp
is to calculate the signal strength of a received signal based on the distance
between the transmitter (target node) and receiver (sensor node) and also based
on the attenuation factor.
This includes the implementation of the following classes:
BatteryBase:
abstract base class for different types of batteries. It defines the ports that
are needed for all types of batteries (e.g., to interface with the CPU and the
Radio models).
BatteryTable: a
class that defines a table that specifies the capacity of a battery as a
function of its current. Capacities at values of current that do not exist in
the table are calculated by interpolation.
BatteryCoinCell:
[3] a derived class of BatteryBase, which implements a coin cell battery. The
implementation is based on the CR1220 coin cell datasheet. BatteryCoinCell
defines a table (instance of BatteryTable) that specifies the capacity of the
battery as a function of its current.
BatteryLiNR: a
derived class of BatteryBase, which implements an LiNR battery. Similar to
BatteryCoinCell, BatteryLiNR defines a table (instance of BatteryTable) that
specifies the capacity of the battery as a function of its current.
BatterySimple: a
derived class of BatteryBase, which implements a very simplistic battery model
whose capacity is always assumed to be constant (i.e., not a function of the
current).
BatteryContract:
defines the contract needed for the battery model to interface with the CPU and
Radio models; for example, so that the CPU and Radio models can inform the
battery about the current that they want to drain from it.
This includes the implementation of the following classes:
CPUBase: abstract
base class for different types of CPUs. It defines the ports that are needed for
all types of CPUs (e.g., ports are needed to interface with the battery model
and other ports are needed to interface with the sensor function model).
CPUAvr: derived
class of CPUBase, which provides reasonable values for active, idle, sleep and
off currents.
This includes the implementation of the following classes:
RadioBase: abstract
base class for different types of Radio models. It defines the ports that are
needed for all types of Radio models (e.g., ports are needed to interface with
the battery model and other ports are needed to interface with the sensor
function model).
RadioSimple:
derived class of RadioBase, which provides reasonable values for transmit mode,
receiver mode, and sleep mode current draws.
In the current implementation, the CPU and Radio models can
report their operation mode to the sensor function model and the sensor function
model can also change the operation mode of both the CPU and Radio models.
However, we let the sensor function model decide what action to take when being
informed of a change in the operation mode of either the CPU or Radio model.
This includes the implementation of the following classes:
SensorPhy: As
mentioned above, this class plays two roles depending on whether an instance of
it exists in the protocol stack of a target node or a sensor node. If it is
defined in the protocol stack of a sensor node, its function is to get from the
sensor channel a copy of a signal (stimulus) generated by a target. Based on the
location of the target node at the time of generating this signal and the
current location of the sensor node, SensorPhy queries the propagation model to
compute the received signal strength; if it is below a certain receiving
threshold (which is one of the member variables of SensorPhy), the signal is
discarded, otherwise, it is forwarded (after being attenuated) up to the sensor
layer.
SensorAgent:
implements the sensor layer. It gets from the sensor physical layer the signal
(stimulus), compiles it and forwards the relevant data up to the sensor
application layer. In the current implementation, the relevant data is: number
of bytes received, the signal-to-noise ratio and the target node ID.
SensorAgentPhyContract: defines the contract needed to define the interface
between SensorPhy and SensorAgent.
SensorRadioPropagationQueryContract: defines the contract needed to define the
interface between SensorPhy and SeismicProp.
This includes the implementation of the following classes:
SensorApp: This
class plays two roles depending on whether an instance of it exists in the
protocol stack of a sensor node or a sink node. If it is defined in the protocol
stack of a sensor node, it gets the relevant data from SensorAgent and forwards
it to the middleware layer between the sensor protocol stack and the wireless
protocol stack so as to go through the wireless protocol stack and then
eventually go through the wireless channel to the sink node.
SensorPacket:
defines the packet that is actually to be sent to the sink node. It includes the
number of bytes received, the signal-to-noise ratio and the target node ID.
SensorAppAgentContract: defines the contract needed to define the
interface between SensorAgent and SensorApp.
Middleware between sensor
protocol stack and wireless protocol stack:
This includes the implementation of the following classes:
WirelessAgent: This
class plays two roles depending on whether an instance of it exists in the
protocol stack of a sensor node or a sink node. If it is defined in the protocol
stack of a sensor node, its function is to get from SensorApp the relevant data
that is to be sent to the sink node (e.g., number of bytes received, the
signal-to-noise ratio and the target node ID) and enclose this data in a
SensorPacket and forward it to the wireless protocol stack so that the
SensorPacket (carrying the necessary information) can go through the wireless
protocol stack and then eventually go through the wireless channel to the sink
node.
SensorAppWirelessAgentContract: defines the contract needed to define the
interface between WirelessAgent and SensorApp.
To build the sensor functional model, we had to integrate
the sensor protocol stack with the wireless protocol stack. This integration was
done, in part, by implementing the SensorApp and the WirelessAgent classes as
described above. We also used the following protocols in the wireless protocol
stack:
- Network Layer: AODV protocol (drcl.inet.protocol.aodv.AODV)
- MAC Layer: MAC 802.11 (drcl.inet.mac.Mac_802_11)
- Physical Layer: drcl.inet.mac.WirelessPhy
- Wireless Channel: drcl.inet.mac.Channel
As shown in Figure 2.c above, a sink node is built in a
plug-and-play fashion using a sensor application layer (SensorApp), an interface
layer (WirelessAgent) with the wireless protocol stack: network layer (AODV
protocol (drcl.inet.protocol.aodv.AODV)), MAC layer (MAC 802.11
(drcl.inet.mac.Mac_802_11)), and physical layer (drcl.inet.mac.WirelessPhy)
In this section, we present the layers of the protocol
stack of the three type of nodes mentioned in Section 2. We also present how
each node connects to other components in the simulation; e.g. sensor channel,
wireless channel, node position tracker, propagation model, etc. A more detailed
description, that also includes ports and contracts, will be given in Section 5.
Figure 3 shows the architecture of a sensor node. Figure 4 shows the
architecture of a target node. Figure 5 shows the architecture of a sink node.
Figure 3: Architecture of a sensor node (dashed line) with its connections to
other components
Figure 4: Architecture of a target node (dashed line) with its
connections to other components
Figure 5: Architecture of a sink node (dashed line) with its connections
to other components
In this section, we present the ports and contracts that
enable the different layers, which are in the protocol stacks presented in
Section 4, to interact. The following figures show this information. Whenever a
Contract name is shown in a figure, the Contract.Message is actually what is
meant.
Figure
6: Ports and Contracts for sensor nodes
Figure 6: Ports and Contracts for sensor nodes (cont.)
Figure 6: Ports and Contracts for sensor nodes (cont.)
Figure 6: Ports and Contracts for sensor nodes (cont.)
Figure 8: Ports and Contracts for sink nodes
Figure 8: Ports and Contracts for sink nodes
In this section, we give a sample script of a wireless
sensor network simulation that has 4 sensor nodes, 2 target nodes and 1 sink
node. The nodes are placed in a 500*400 m2 terrain as shown in Figure 9. The
sensor and sink nodes are stationary, but the two target nodes are moving with a
30 m/sec. speed.
Figure 9: A Wireless Sensor Network. Target Nodes are moving with a 30 m/sec.
speed
The script is available here. Figure 10
shows the signal-to-noise ratio (SNR) collected at the sink node for the two
target nodes.
Figure 10.a: SNR collected at the sink node for the target node at (550, 250)
Figure 10.b: SNR collected at the sink node for the target node at (400, 450)
References
[1] Sung Park, Andreas
Savvides, and Mani B. Srivastava, “SensorSim: A Simulation Framework for
Sensor Networks”.
[2] Sung Park, Andreas Savvides, and Mani B. Srivastava, “Simulating Networks
of Wireless Sensors,” Proceedings of the 2001 Winter Simulation Conference.
[3] Sung Park, Andreas Savvides, and Mani B. Srivastava, “
Last modified by Ahmed Sobeih on 12/23/2003