Agent based platform for the design and simulation of
wireless sensor networks
Abdelhakim Hamzi 1,2
College of Computer and Information Sciences
Al-Jouf University
Sakaka, KSA
amhamzi@ju.edu.sa , a_hamzi@esi.dz
Abstract— in this work we propose a flexible, generic and agent
based platform for the design and simulation of wireless sensor
networks (WSN) protocols and applications. This platform is
independent from the physical architecture of nodes, where each
node is considered as an autonomous agent having its own
properties and behaviors according to the role it takes in the
network. Once the description of the WSN is done using agent
models, we can translate them to the simulation environment or
directly to the physical network architecture using a translation
library witch makes the correspondence between agent models
and the target environment. To validate our work, we have
extended OMNeT++ with new models for WSN and implemented
some functions that translate automatically the agent models of
the WSN nodes to OMNeT++ source code.
Keywords- wireless sensor networks, multi-agent system,
network simulation, OMNeT++
I. INTRODUCTION
Recent advances in wireless networking and MEMS
technology have enabled the development of small, low-cost,
and multifunctional sensor motes. A wireless sensor network
(WSN) is composed of a large number of sensors that are
densely deployed in some geographical area and communicate
through a wireless media. The purpose is to collect data from
the environment or target objects in order to perform some
processing on them. Indeed, these devices are being considered
for a wide variety of civil and defense applications in
transportation, safety, agriculture, medical, environmental,
battlefield and disaster recovery systems [1].
These networks pose important challenges for engineers
working in the development of the related control systems:
potential high number of nodes, limited resources, sensor
heterogeneity, unreliable networks of changing topology, and
several levels of data processing. In the most case, users (and
programmers) of WSNs are often not software engineers but
domain experts in other fields. So it is necessary to have
middlewares and platforms helping the development of WSN
applications.
The concept of an agent provides a convenient and
powerful way to describe a complex software entity that is
capable of acting with a certain degree of autonomy in order to
978-1-4673-1550-0/12/$31.00 ©2012 IEEE
Mouloud Koudil
Laboratoire de Méthodes de Conception de Systèmes
Ecole Nationale Supérieure d’Informatique (ESI)
Algiers, Algeria
m_koudil@esi.dz
accomplish some tasks. Our work consists of implementing a
generic, flexible platform based on agents, for modelling and
simulating WSNs. In our approach, each node is considered as
an autonomous agent having its own characteristics, according
to the hardware architecture of a node and that of the network,
as well as the behaviour of a sensor according to its role in the
network.
The remainder of the paper is organized as follows. In the
second section we will present the architectures and
characteristics of WSNs and their development challenges. In
the third section, the architecture of the proposed platform is
presented. The fourth section contains the models of the
platform. The fifth section presents the interface and the last
one is a conclusion and perspectives.
II. BACKGROUND
A. WSNs architecture and characteristics
There are significant differences between WSNs and
classical networks. For this, in the majority of case we can’t
apply the same programming techniques. The power
consumption is the important constraint which must be taken in
consideration because of the cost of replacing the battery
especially in sensible environments. The architecture of a WSN
may be viewed, according to [2], as follows:
1. Infrastructure: Consists of the sensors and their current
deployment status.
2. Network Protocols: Are responsible for creating paths and
accomplishing communication between the sensors, the
base station and the observer.
3. Application/Observer: Interests in the phenomenon are
queries from the observer(s). These queries could be static
(the sensors are preprogrammed to report data according to
a specific pattern) or dynamic.
The topology of a WSN can be seen according to the
mobility of nodes as static, mobile and hybrid networks.
According to the structure of nodes, we have two main
architectures which influence significantly rooting protocols
[4]: in flat networks, each node typically plays the same role
and sensor nodes collaborate together to perform the sensing
task. In a hierarchical or cluster-based architecture, higher
energy nodes (cluster-heads) can be used to process and send used in order to facilitate this task such as Object-Oriented [5],
information while low energy nodes can be used to perform the Component-Oriented [6], Service-Oriented [7] and Agent-
sensing in the proximity of the target. Oriented programming [8].

Figure 1. WSN architecture overview

Like all networks, the communication architecture in WSN

is based on layers or protocol stack. Whereas the main function
of a WSN isn’t only to ensure the communication between
nodes, the protocol stack can be extended with a power
management plane, mobility management plane, and task
management plane [3].
Although WSNs share common problems and solutions
with embedded systems and ad hoc networks in what concerns
hardware and network issues, there are new challenges that rise
from the fact that these devices are resource constrained in
term of energy, processing, storage and communication
capabilities. The table below presents a comparison between
sensor network technologies and other monitoring technologies
[4].
Figure 2. WSN applications design and maintenance process
TABLE I. DIFFERENCES BETWEEN SENSOR NETWORK TECHNOLOGIES AND
OTHER MONITORING TECHNOLOGIES Various agent-oriented methodologies, metamodels and
architectures exist to design and develop distributed and
Sensor Networks Alternative technologies complex systems in an abstract manner. Regarding to WSN,
Low-cost low-power simple sensors Expensive high-power consuming almost contributions focus on the use of mobile agents to solve
complex sensors a particular problem such as routing, clustering, deployment,
Cover wide-range areas Cover small-size areas localization and security [9]. To make programming mobile
agent for WSN easier, some architecture was proposed. The
Monitor remote or hostile Monitor highly-controlled
environments environments
most popular are Sensorware [10] and Agilla [11].
Fault-tolerance and robust to node Non-robust Frequently, almost proposed architectures and frameworks
failures specialize on particular parts of WSN design and applications
Non-invasive Invasive and only few works have been invested to derive a general
Irregular sampled datasets Regularly sampled datasets
architecture. This field still needs more investigation. Our work
fills in this objective. It defers from related works in term that it
Intrinsic distributed structure Intrinsic centralistic structure tries to cover almost WSN’s application requirements and
Low-bandwidth connectivity High-bandwidth connectivity different kind network topology and nodes architecture.
Battery-powered Electric-powered
III. THE PLATEFORM ARCHITECTURE
B. Designing WSNs
A. Aproach description
Designing and programming WSNs is a complex task as
system level code and application level code are often During the implementation of protocols or applications for
intertwined (Figure 2). The users (and developers) of WSNs WSN, the design phase is very important and it is closely
are often not software engineers but domain experts in other related to the hardware architecture of nodes as well as the
fields, who use WSNs to obtain data relevant to their work. target network and the simulation environment used for testing
Although this disparity in expertise, they are required to the performance. Sometimes we need to use more than one
operate in a concurrent, real-time, resource constrained simulator for testing different aspects of the application.
computing environment that is potentially complex and hard to Furthermore, a small change in the physical architecture of
program correctly. Several programming approach have been
nodes or the network can return as to the design phase for User
rectifying the solution or even changing it completely. Interface

What we propose is to make the design phase of protocols,

and applications for WSN the most general as possible and Nodes Protocols Agents Networks Running and
independent from the target architecture (the physical WSN, or description implementation models description statistics
the simulation environment). This is done by the abstraction of
the node to a configurable and controllable agent. Using this Nodes Protocols Agents Networks
approach of modeling, the designer must be able to define all Lib Lib Lib Lib

characteristics of nodes (physical components and their Configuration

properties, information related to the network architecture, and Components parameters *.xml
description
features of communication) and their behaviors towards
various events they receive (receiving and sending data, data Models
processing, update the node states and its components ... etc). translation

Once the description of agents is done by high level primitives, Translation functions
translation functions are used in order to transform these library
Source file Compiling
agents’ descriptions to the simulation models or to the code generation and
running
source of the physical sensor. For each simulation Library
update
environment and physical architecture of WSN (Sensors and
network architecture) there are a set of translation functions
that make the correspondence between the agents’ models and Simulation interfaces
the code source of the target environment. The Figure 3 is a
layered view of the proposed architecture.
Figure 4. The architecture of the proposed platform

The different descriptions of models for nodes, protocols,

networks and agents are stored in libraries using XML
representation which facilitate their translation into new
simulation environments. The translation of models is done
automatically by generating the source file implementing them
in the target simulator from the XML descriptions.
In the first time, we implemented the translation functions
that generate the code for OMNeT++ after extending it with
Figure 3. Layered view of the proposed plateform
new models for WSN simulation.

B. The architecture of the platform

The platform must take in consideration three levels: IV. THE PLATEFORM MODELS

• Physical architecture of nodes: The model of the node A. Node components models
can represent a physical device that exists in the market Nodes models must take in consideration either hardware
as it can be built by the designer (virtual node) by and software aspect. A node is composed of modules that
defining its components and their characteristics. communicate directly (physical link) or by messages. The next
• Protocols architecture: To facilitate the implementation figure illustrates an abstraction of the node components.
of a new protocol, the designer has to define the fields
of the message traversing the different layers, the Sensing Sensor Application
channel
processing to be performed on this message and how it module module
will be transmitted to the next layer. Processing
module
• Network architecture: The definition of the network is Target Power Network module
done by selecting the nodes and their roles (defining Object module
Controller

their models or importing them from a library of nodes), Generator

the manner of deployment (random or predefined), the module MAC module
architecture (hierarchical or flat), communication Localization
Communication

module
protocols and the target objet that generate events.
channel

Physical module
Actuator
The next figure shows the different components of the module
architecture of our platform. Radio
module
The Node
Direct communication
Messages communication
Figure 5. The model of the node architecture
 The controller is the main agent of the node that b) Control methods :define a set of methods for handeling
coordinates between the hardware and the software modules. the agent charactersitics (components properties, node
The characteristic and methods of each module will be state and position , nighbors list,…).
represented by an XML schema.
c) Behaviors methods: define the actions to acomplish
according to the events received whether internal (state
B. Agents model
change, messages exchanged between components
1) Types of agents module or communication layers,..) or external (query
According to the network architecture, the physical received, data captured, message received from
components of nodes and their positions in the network, we can neighbor,…).
distinguish several types of agents:
Agents’ models are represented by XML schema in order to
• Base Stations’ Agents: the Base Station is the interface generate the source code according to the simulator used.
between the WSN and the observer .they can be fixed or
mobile. the main behaviors of this type of agents are : <agent>
<identification>
ƒ Queries definition: the Agent maintains some tables of <id> </id> <name> </ name > <type> </type> <author> </author>
queries (according to the application of the WSN) </identification>
<characteristics>
with a list of neighbor nodes (Agents) that directly <hard>
communicate with the BS. An entry of a query table is <node>
a triplet (Attribute, Operator, Value). <!...Import XML description of node components ….>
</ node>
ƒ Data processing: preparing data for the observer. This </hard>
is done in the application layer and it differs from <soft>
other processing tasks related to the routing protocol. <simple>
<type> </type> <value> </value>
ƒ Communications: can be either with the observer </simple>
using a specific protocol and the WSNs using the <structure>
routing protocol. <static>
<dimension> </ dimension>
• Network Agents: the type of these agents is based on the <type> </type> <value> </value>
<static>
role of the node in the network. Several factors <dynamic>
influence the definition of the characteristics and <simple> </simple>
behaviors of the agent: <structure> </structure>
</dynamic>
ƒ Physical architecture of nodes: some nodes have more </structure>
processing, storage and energetic capacity. Others can </soft>
</characteristics>
have specific sensing capabilities. <behaviors>
<behavior>
ƒ Communication protocols: the role of the agent in the <conditions>
communication protocol defines its behaviors. For < cond_name>
example some nodes can be elected as cluster-head. <par_g> </par_g> <op> </op> <par_d> </ par_d >
< cond_name>
ƒ Network architecture: Generally, nodes located in the <and_cond>
border of the network are oriented for capturing <conditions> </conditions>
measures while nodes located inside the network are </and_cond>
<or_cond>
oriented for processing and routing. <conditions> </conditions>
</or_cond>
• Target objet agent: it represents either a physical object </conditions>
that we want to monitor their movements or particular <actions>
points in the network that are a source of measures. The <corp_action> </corp_action>
role is to generate events to be captured by the sensor </actions>
</behavior>
nodes. <behaviors>
</agent>
2) Agent description
Each agent is defined by three part modeling its
characteristics and behaviors: C. Protocols models
Each layer in the protocol stack provides communication
a) Agent characteristics : contains identification services allowing data exchanges between nodes. A layer
informations related to the node (Id, name, fabricant,..), receives an SDU (Service Data Unit) from the upper layer,
hardware components and their characteristics, and adds its own information (Protocol Control Interface) as header
network informations (node type, position, nighbor and constructs the PDU (Protocol Data Unit) to send to the
nodes list, queries and routing tables,…). lower layer. For implementing a protocol, the platform allows
to the designer to define the header fields, their control
methods and the processing methods.
 1) Protocol Control Interface: for each layer a sub class
(hiretate from the base class modeling a layer) is generated, it
contains the fields of the header defined by the user and the
control methods for the manipulation of these fileds. For
example for the filed destination the two methods
set_destination and get_destination are generated
automatically.
2) Processing methods: the subclass of each layer defines
three kind of methods for implementing the services garanted
by this layer : receive, handle and send. The first one is
executed when receiving a message for preparing it for the
processing done by the second method, and the third one
prepare the PDU (SDU) to be sent for the next layer. For each
method there are two versions, for example the method
receive_up is executed when receiving an SDU from the uper
layer and receive_down when receiving a PDU from the
lower layer.
The designer has the possibility to implement his own
methods to add to the layer subclass by defining the name of
the method, its parameters and the body code. All these
protocols descriptions are represented by an XML schema and
added to the protocols library.
V. IMPLEMENTATION AND INTERFACES
The platform is composed by several interfaces. The node
interface used for defining the nodes components and there
characteristics. The protocol interface allows writing the
implementation of new protocols. Using the nodes and
protocols descriptions the agent interface allows defining the
type, characteristics and behaviors (tasks and actions) of the
agents.
The network is defined by the sensing area, agents (target
object, base stations and network nodes), and the method of
deployment. All models will be translated to the target
simulator code source (in our case OMNeT++ modules). Once
done, the designer can lunch the simulation via the interface of
OMNeT++. The figure shows the principal interface of the
platform.
Figure 6. The main interface of the platform
VI. CONCLUSION
We proposed a platform for designing and simulating
protocols and applications for WSNs based on the paradigm of
agents. Our approach is to abstract the physical characteristics
of the network nodes and their behaviors to autonomous
agents. Modeling agents is done through an XML schema.
Once completed, it is translated into source code for the target
environment (simulator or real network). To support multiple
target environments, it is enough enriching the platform with
translation functions that make the correspondence between the
agent-based modeling and the target environment. To validate
our approach, we extended OMNeT++ with new modules for
supporting WSN functionalities. The defined architecture is
scalable and generic. It allows the designer to define their own
models for nodes components and communication protocols.
As future work, we will try to implement translation functions
to support other WSN simulators, emulator and operating
system.
REFERENCES
[1] Ning Xu. A Survey of Sensor Network Applications. Computer Science
Department, University of Southern California. 2003.
[2] Sameer Tilak, Nael B. Abu-Ghazaleh and Wendi Heinzelman. A
Taxonomy of Wireless Micro-Sensor Network Models. Mobile
Computing and Communications Review, Volume 1, Number 2. 2002.
[3] Ian F. Akyildiz, Weilian Su, Yogesh Sankarasubramaniam, and Erdal
Cayirci. A Survey on Sensor Networks. Georgia Institute of Technology.
Pages 102-114, IEEE Communications Magazine. August 2002.
[4] M. Vinyals, J.A. Rodriguez-Aguilar, J. Cerquides. A survey on sensor
networks from a multi-agent perspective. In Proceedings of the 2nd
International Workshop on Agent Technology for Sensor Networks
(ATSN 2008), Estoril, Portugal, 2008; pp. 1–8.
[5] Žarko Živanov, Predrag Rakić and Miroslav Hajduković. Wireless
Sensor Network Application Programming and Simulation System.
Faculty of Technical Sciences, Trg D.Serbia. ComSIS Vol. 5, No. 1,
June 2008.
[6] A. Dearle, D. Balasubramaniam, J. Lewis, R. Morrison. A Component-
based Model and Language for Wireless Sensor Network Applications.
32nd Annual IEEE International on Computer Software and
Applications, 2008. COMPSAC '08. Page(s): 1303 – 1308. 2008
[7] E. Meshkova, J. Riihijarvi, F. Oldewurtel, C. Jardak, P. Mahonen.
Service-Oriented Design Methodology for Wireless Sensor Networks: A
View through Case Studies. 2008 IEEE International Conference on
Sensor Networks, Ubiquitous, and Trustworthy Computing. Page(s): 146
– 153. IEEE 2008.
[8] Zahia Guessoum and Jean-Pierre Briot. From Active Objects to
Autonomous Agents. Concurrency, IEEE .Volume: 7 , Issue: 3 .
Page(s): 68 – 76.1999
[9] Chen Min, S. Gonzalez, V.C.M. Leung. Applications and design issues
for mobile agents in wireless sensor networks . Wireless
Communications, IEEE . Volume: 14 , Issue: 6 , Page(s): 20 – 26. 2007.
[10] Athanassios Boulis , Chih-Chieh Han , Roy Shea, and Mani B.
Srivastava. SensorWare: Programming sensor networks beyond code
update and querying. Pervasive and Mobile Computing. Volume 3
, Issue 4.ACM, August 2007.
[11] Chien-liang Fok, Gruia-catalin Roman, and Chenyang Lu. Agilla: A
Mobile Agent Middleware for Self-Adaptive Wireless Sensor Networks.
ACM Transactions on Autonomous and Adaptive Systems, Vol. 4, No.
3, Article 16, Publication date: July 2009.