D. GEORGOULAS ET AL.
159
consume 135 bytes of virtual memory from the In-Motes
engine.
The Slave category consists of mobile code that is re-
sponsible for capturing the available nodes in the wire-
less sensor network. By the term capture we mean the
ability to assign a predefined number of N nodes under
the same facilitator In-Motes agent. Slave agents are
practically clones of the facilitator ag ents and they do not
provide any local decision making. After a successful
capture of a node they report back to the facilitator agen t
and then die. Each slave agent being a facilitator clone
consumes 135 bytes of virtual memory during its active
period.
The Job category consists of mobile code that is re-
sponsible for carrying out the user requests to the wire-
less sensor network. Their role is to collect readings from
the sensing devices of the hardware and their specifica-
tion is tightly bound with the application. Thus, a job
In-Motes agent could be reporting temperature, light or
acceleration readings to the facilitator agent. They can
report only one set of readings at the same time. Job
agents are able to be transferred either by cloning or by
migrating inside the wireless senor network based on the
application and the available memory. Therefore, for
large scale, complex applications which needed most of
the memory resources, job agents are migrating while for
simple applications they are cloning. The difference be-
tween cloning and migrating is based on how the code is
transferred inside the wireless sensor network. Thus, a
Job agent is migrating wh en the same cod e is visiting the
predefined nodes alters their parameters, but it never
stays resident in any of them, while with cloning, a Job
agent creates multiple copies of its code that are trans-
ferred and stay resident in all the predefined nodes.
According with their status, defined as static or dy-
namic, In-Motes job agents are able to provide a simple
level of local decision making. The term “static” de-
scribes In-Motes job agents which perform a single user
request measurement and then die while “dynamic” de-
scribes In-Motes job agents which perform multiple
measurements and respond to changes in user defined
parameters. The dynamic In-Motes job agents consume
118 bytes of virtual memory and they migrate inside the
system while the static ones 68 bytes and they clone in-
side the wireless sensor network.
The Fix category consists of mobile code that is used
as a debugging tool for the wireless sensor network.
Their role is to flush the memory of a single node in case
of a problem such as buffer overflow or to flush the
memory of the total number of nodes of the network.
They are small in size, 25 bytes, and do not provide any
local decision making.
The In-Motes architecture is divided in two layers [8].
The first layer consists of the In-Motes agents that were
described above. Based on the fact that we could have
one or more mobile codes active at the same time on the
same node lead us to the need for a second layer that
apart from the In-Motes engine would include a manager
scheme for regulating issues such as context and reac-
tions. Without this layer th e In-Motes agents would have
a loose hierarchy that would lead to confusion between
their roles and responsibilities inside the wireless sensor
network and also the system would consume unnecessary
physical and virtual memory. Thus, the second layer
consists of a facilitator manager, agent manager, rules
manager, operation manager and an instruction manager
Figure 1.
The In-Motes instruction set is based on those of
Agilla and Mate. However, there are many modifications
and differences in order to support the facilitator agent’s
scheme and the tuple space operations [9].
The In-Motes communication protocol [10] is based
on the federation communication scheme. A facilitator
In-Motes agent is send to the network in order to capture
and create facilitator and slave nodes before any user
requests or the actual application is forwarded. The life
cycle of a facilitator In-Motes agent is shown in Figure 2.
The facilitator agent works by continuously checking
whether any of the nodes are available for capture. The
user sends a single facilitator into the wireless sensor
network, although this is not limited by the In-Motes
infrastructure, allowing more than one facilitator to be
deployed in large scale applications where the nodes
exceed the total number of 20.
Upon arrival at the first available node, the facilitator
will insert a facilitator tuple into the tuple space assign-
ing thus the first facilitator node. The capturing proce-
dure takes place when a facilitator agent during its mi-
gration registers a capture or a slave reaction to the cor-
responding node. An alternative is for the facilitator
agent to clone rather than migrate and generate a slave
agent inside the wireless network.
A counter will be incremented every time a capture
reaction takes place; when the counter reaches two, the
facilitator agent will migrate again to the next available
node assigning this time around a new facilitator tuple
and slave reaction and the capturing procedure will re-
peat.
It is expected that during the lifetime of a wireless
sensor network some nodes will eventually die and in-
formation will be lost. In-Motes can adapt and dynami-
cally take actions upon unexpected scenarios like the
ones mentioned above. If a facilitator node goes down
the network will dynamically adapt since the lifecycle of
the facilitator agent that we described above never ter-
minates and a new capturing procedure will take place.
Copyright © 2011 SciRes. WSN