2011
2011Tenth
10th International
InternationalSymposium
Symposiumon
onAutonomous
AutonomousDecentralized
DecentralizedSystems
Systems
MASPOT: A Mobile Agent System for Sun SPOT
Ramon Lopes and Flávio Assis
LaSiD - Distributed Systems Laboratory
DCC - Department of Computer Science
UFBA - Federal University of Bahia
Salvador, Brazil
Email: [email protected], [email protected]
Carlos Montez
DAS - Department of Automation and Systems
UFSC - Federal University of Santa Catarina
Florianópolis, Brazil
Email: [email protected]
Mobile agents have been proposed as a means to address these issues [4], [5], [10], [15]. A mobile agent is
a software component that is able to migrate from node to
node of a network. When it moves, the execution of the
agent is interrupted, its code, data state and possibly its
execution state are transferred to another node, and, after
being installed on this node, it resumes execution. Mobile
agents can contribute to the reprogramming of a WSN since
they carry code that is automatically installed along their
paths. Mobile agents might also contribute to reduce the
amount of energy spent by a WSN since they can locally
(at each node) read sensor data, process them and aggregate
(or fusion) data from different nodes on their way through
the network (e.g., [4]). Potential benefits of mobile agents
have already been pointed out in the context of traditional
distributed systems [8] and their applicability can naturally
be extended to WSNs.
Different platforms and middleware have been developed
to support the execution of some sort of code migration
on WSN [3], [5], [13], [1], [7], [18]. In this paper we
describe MASPOT, a mobile agent system for the Sun SPOT
(Sun Small Programmable Object Technology) platform [2].
Our interest in developing a mobile agent system for this
platform arose from the fact that Sun SPOT nodes have much
more resources (memory and processing) than other typical
sensor nodes. Thus, this platform allows us to develop
much more complex applications. Additionaly, Sun SPOT
applications are writen in Java. This allows us to write
mobile agent applications using a general purpose and highlevel programming language. Many different projects are
being developed based on Sun SPOTs [11].
Adding mobile agent functionality to Sun SPOT extends
the range of applications of this platform, as pointed out
by Sun SPOT developers [2]. Beyond MASPOT and a
native form of process migration in Sun SPOT (described
in Section III), there are only two other systems for this
platform which implement some form of process migration, MAPS (Mobile Agent Platform for Sun SPOTs) [1]
and AFME (Agent Factory Micro Edition) [13]. However,
MAPS, AFME and the native form of process migration
in Sun SPOT do not provide code migration, a fundamental
Abstract—Mobile agents have been proposed as a means to
address two important issues in the design of Wireless Sensor
Networks (WSN): the need for reprogramming the network
and decreasing energy expenditure. However, few mobile agent
systems have been developed for WSN so far. In this paper
we describe MASPOT, a mobile agent system for Sun SPOT,
a WSN platform developed by Sun Microsystems. MASPOT
provides a solution to the issues above and extends the range
of Sun SPOT applications. To the best of our knowledge,
MASPOT is the only Java-based mobile agent system for
WSN that currently supports code migration. We describe the
system and present the results of an experiment to evaluate the
amount of energy spent during agent migration. It showed that
migration spends around 0.03% of the nodes battery energy.
Additionally, MASPOT uses only around 1.5% of the available
flash memory of Sun SPOT nodes.
Keywords-Mobile Agents; Sun SPOTs; Wireless Sensor Networks; MASPOT;
I. I NTRODUCTION
A Wireless Sensor Network (WSN) is a network used for
sensing or monitoring a specific phenomenon or condition
of an environment and possibly actuating on it. A WSN
is composed of (typically many) sensor nodes and one (or
more) base stations. A sensor node is a device equipped
with a power, a processing (CPU and memory), a wireless
communication and a sensing (temperature, pressure, among
others) unit. The sensing data collected by the sensor nodes
are sent to the base station(s), which is(are) a device(s)
responsible for processing the sensed data and/or forwarding
them to some processing system elsewhere.
For many WSN applications, human access to nodes after
network deployment is not possible or desirable. This has
at least two implications: the lifetime of nodes must be
extended as much as possible since it will not be possible
to replace or recharge their batteries; and the network and
applications running on it must be managed remotely. In
particular, the network and applications should be able to
be reconfigured remotely. More generally, sensor networks
should be reprogrammable [4], [5], [10]. This means that it
should be possible to modify and add software components
running on each node as well as dynamically add new forms
of querying or processing data sensed by the network.
978-0-7695-4349-9/11 $26.00 © 2011 IEEE
DOI 10.1109/ISADS.2011.10
25
aspect of the mobile agent paradigm. Thus, to the best of our
knowledge, MASPOT is the only Java-based mobile agent
system for wireless sensor networks that currently provides
code migration. MASPOT offers services that implement
the basic mobile agent life cycle (creation, initialization,
execution suspension, execution halting, cloning and migration) and a communication service which provides primitives
for communication between agents (based on tuple spaces)
and between agents and the base station (based on message
passing). Additionally, MASPOT uses only around 1.5% of
the available flash memory of Sun SPOT nodes and spends
around 0.02% of the battery energy of nodes for moving
an agent. This supports the viability of using mobile agents
with MASPOT. As pointed out previously, Sun SPOT has a
vast range of applications [2]. MASPOT adds flexibility to
this platform and extends the range of Java-based wireless
sensor networks applications that can be built using current
technology.
We would like to emphasize the particular suitability of
using mobile agents to perform what we call transitory
queries on a WSN. It is very difficult or impossible to
foresee all the requirements of a dynamic system due to
natural evolution of user requirements. We envisage WSN
users’ need for performing specific queries on the whole
or part of the WSN which are of temporary interest. For
example, suppose a WSN was designed so that each node
sensors the temperature of a given area periodically and only
sends the mean of k consecutive samples to the base station.
If the user of the WSN needs, for some reason, the maximum
sensored value among the samples, he/she will not be able
to extract this information from the sensed data (at the base
station). Mobile agents are suitable for implementing such
queries, since they can move to the specific nodes where
data are to be collected and process them locally according
to the new requirements, without the need for changing the
configuration of the underlying software installed on the
nodes. This particular benefit of using mobile agents in WSN
was not previously emphasized in the literature.
This paper is structured as follows. Section II introduces
the main aspects of the Sun SPOT platform. Section III
describes MASPOT, including: a general description of the
MASPOT architecture (Subsection III-A); details of the
implementation of mobile agents (Subsection III-B); the
inter-agent communication service (Subsection III-C); and
a description of the primitives to support communication
between the base station and mobile agents (Subsection
III-D). Section IV presents an evaluation of the cost, in terms
of energy, of mobile agent migration. Section V describes
related work. Finally, Section VI concludes the paper.
Each node is equipped with an ARM-9 processor, 512 KB
of RAM, 4 MB of flash memory and a Chipcon 2420 radio
device (compliant with IEEE 802.15.4) with an on-board
antenna which ranges up to 100 meters. Each node has a
light and a temperature sensor, a 3-axis accelerometer and
eight tri-color LEDs. A Sun SPOT node weighs 54 gramms
and its dimmensions are 41 x 23 x 70 mm.
Sun SPOT nodes run a special Java virtual machine,
called Squawk [16], [2]. It is a virtual machine with a
small footprint that runs without an underlying operating
system (it runs on bare metal). Written mostly in Java
and fully J2ME CLDC 1.1 [12] compliant, Squawk provides a compact garbage collector, thread scheduler and
the Isolate mechanism. The Isolate mechanism refers to an
API for managing Java applications independently one from
the others. Each application on Squawk has, as its main
component, a Java object that is an instance of the Isolate
class. Multiple Isolates can run on a single virtual machine
and be independently started, paused, resumed, halted and
migrated.
Squawk does not support dynamic class loading. Before
an application can be installed at a node, all the needed
classes must be preprocessed and packaged in a special file,
called a suite.
Suites are installed on Sun SPOT nodes at specific addresses called slots. Sun SPOT nodes have only seven slots.
Sun SPOT does not support dynamic address resolution.
Therefore, addresses in a suite are statically allocated, relative to a specific slot. When the code of a suite is generated,
the system checks which is the first non-allocated slot at the
node where the suite is to be installed. Then, addresses in
the suite are defined relatively to this slot. Thus, the suite
can only be installed at that specific slot on any node. This
dependence on a specific slot restricts code migration on
Sun SPOTs.
Squawk natively provides a mechanism to migrate running
Isolates between nodes, so that an Isolate execution can
be interrupted at an arbitrary execution point, be streamed
to a remote device over the radio, and be resumed at the
new node [17]. However, this mechanism does not support
code migration, i.e., only the execution state of an Isolate
is migrated. The suite (application code) must have been
previously installed on the new node.
Additionally, the Sun SPOT platform provides an API to
access node hardware resources, such as the accelerometer,
light sensor, LEDs, temperature sensor and radio device.
It provides the Generic Connection Framework (GCF) to
handle connections, such as HTTP, datagram or stream
connections.
II. S UN SPOT AND S QUAWK
III. MASPOT
A. System Overview
Sun SPOT is a platform for wireless sensor networks
developed by Sun Microsystems (currently Oracle) [2]. Sun
SPOT nodes are resource-richer than typical sensor nodes.
Figure 1 illustrates the main MASPOT components. A
MASPOT system is composed of a set of sensor nodes, a
26
around 580 kbytes. Therefore, MASPOT occupies around
12% of additional memory on the nodes. Sun SPOT nodes
have 4MB of flash memory available for the storage of suites
and application codes. Thus, MASPOT uses only 1.5% of
this memory capacity.
B. Agent Implementation
Figure 1.
In MASPOT, an agent is a standalone application.
MASPOT requires that an agent inherits from a predefined
class called Agent, which provides methods for migrating,
cloning and opening communication connections to the base
station.
Users of MASPOT create agents with the MASPOT
Management Application (on the user station). Once created
and started, an agent is inserted into the network through
the base station. During its execution, an agent might create
other agents, called its child agents. Child agents migrate
and execute independently of its parent agent.
Each agent has an id. Agents created directly by users of
MASPOT have ids allocated by the MASPOT Management
Application. The id of a child agent is created by appending
suffixes to its parent id, so it remains unique in the whole
system.
An agent is structurally composed of: its code; internal
data, i.e., agent application data; metadata, i.e., data that
represent information about the agent itself, such as agent id;
and execution state, i.e., data about its execution context(s),
including the state of the execution stack.
MASPOT supports both strong and weak migration. In
strong migration, the execution state of the agent (execution
stack) is transferred during migration along with the agent
data state, metadata and code; in weak migration, only
the code, data state and metadata is transferred. In weak
migration, the information needed for the agent to resume
execution after migration (at the destination node) must be
represented in the data state. In this case, an agent always
resumes execution from the beginning of its code (Main
method). In MASPOT, the type of migration is associated
with each agent at creation time, and the migration type does
not change during the agent’s life cycle.
As described in Section II, all classes needed by an
agent are previously packaged on the user station in a suite,
called here the agent suite. The Isolate migration mechanism
does not fulfil the migration requirements for implementing
mobile agents completely since it does not provide code
migration. Thus, MASPOT provides functions to transfer
agent code between nodes.
When an agent migrates, the agency where it currently is
(the origin agency) sends a message to the agency where
the agent wants to move to (the destination agency) to ask
it whether it already contains the agent suite (a suite is
identified by a URI - Uniform Resource Identifier). If yes,
the data state, metadata and, in case of strong migration,
also the execution state are transferred to the destination
MASPOT: System Overview
base station and a user station. The base station is connected
to the user station. The user station is a computer through
which MASPOT users interact with the WSN.
MASPOT has software components running on each node
and on the user station. The MASPOT Management Application runs on the user station. This application is used to
create, configure and remotely manage agents. A MASPOT
agency runs on each node. An agency represents the set of
all software components that are needed for supporting: the
agent life cycle, i.e., agent reception, instantiation, execution,
migration, destruction; control over the execution of agents
(interrupting, resuming and halting); and communication
between agents, and between agents and the base station.
We also use the term agency to refer to the (logical) places
in the distributed system where mobile agents can move to.
An agency is composed of the following main components
(see Figure 1):
1) Mobile Agent Manager: responsible for controlling the
execution of agents;
2) Mobile Agent Transport Service: responsible for receiving (receiving, deserializing) and sending (serializing, transmitting) agents;
3) Tuple Space Manager: responsible for managing a
local tuple space;
4) Communication Service: responsible for executing the
communication protocol between the base station and
mobile agents.
The design of MASPOT considered OMG/MASIF (Object Management Group / Mobile Agent Facility) [14] as
a reference. MASPOT has procedures for supporting the
life cycle of agents that are similar to methods contained in
MASIF interfaces. Additionally, the MASPOT primitives for
supporting communication between the base station and the
mobile agents are similar to procedures defined in MASIF
for finding agents. However, MASPOT is not compliant with
MASIF.
Wireless communication is performed using IEEE
802.15.4 (Sun SPOT built-in feature), a protocol that is
becoming a de facto standard in WSNs.
MASPOT was implemented integrated with the Sun SPOT
platform. The Sun SPOT libraries occupy around 520 kbytes
on the nodes. Sun SPOT and MASPOT together occupy
27
agency. Otherwise, the agent suite is first sent and then the
data state, metadata and, in case of strong migration, the
execution state.
As previously explained, a suite is dependent on a specific
slot number. In MASPOT, code (suite) migration can only
occur if the slot associated with the suite is available at
the destination node. If yes, the suite is read from the flash
memory on the origin node, serialized, fragmented in 512
bytes packages, and sent through the wireless channel to the
destination node. If the slot is already in use, the migration
process is aborted. A slot becomes available if there are no
more agents in the agency whose suite is installed at that
slot. The 512 bytes restriction is a limitation of the Sun
SPOT communication stack.
Reallocating internal addresses in the agent suite code so
that it could be installed in a different slot was considered as
an alternative to implement agent migration. However, this
process incurs a high energy expenditure by the nodes before
agent migration (thus we did not choose this alternative).
Figure 2.
Chain of References
C. Inter-Agent Communication Service
In MASPOT, inter-agent communication is provided by
tuple spaces [6]. The tuple space model implemented is
analogous to the model used in Agilla [5].
A tuple is an ordered set of values. In MASPOT, each
value in a tuple might be of one of the following types:
boolean, byte, double, int, long, string or array of any of
these types. A tuple space is a repository of tuples. In
MASPOT, there is a tuple space locally at each agency.
Tuple spaces can be accessed remotely, but tuple spaces in
different hosts are independent of each other, i.e., there is
no procedure for maintaining consistency between them (as
would be the case in a distributed implementation of a tuple
space, as described in [6]).
Tuples can be: written in the tuple space, by using the
out operation; removed from the tuple space, by using
the in operation; or read without being removed from the
tuple space, by using the read operation. These operations
are executed atomically. The in and read operations are
executed associatively, i.e., for removing or reading tuples
a pattern consisting of specific values and/or wildcards is
provided, specifying the number and specific values for tuple
fields. A tuple can be removed or read from the tuple space
if its values satisfy this pattern.
As in Agilla, in MASPOT callback functions can be
associated with operations on tuple spaces. A mobile agent
can be notified when a tuple that satisfies a given pattern
is written or removed from the tuple space. The operations
read and in can be blocking or non-blocking. The three
tuple space operations can also be executed remotely, i.e.,
an agent at a node can use these operations to access a tuple
space on another node. Remote operations on tuple spaces
are non-blocking. Tuple spaces are volatile in MASPOT.
Figure 3.
Loops in Chain of References
D. Communication between Base Station and Mobile Agents
One of the main communication patterns in a WSN
is convergecast, where nodes send messages to the base
station. Routing in WSN is thus mainly tailored to execute
convergecast efficiently. Considering this, messages from
mobile agents to the base station are sent using Sun SPOT
built-in routing protocol.
Communication from the base station to a mobile agent,
however, requires support for agent mobility. MASPOT
provides three primitives for this: TUnicast, PUnicast and
Broadcast. These primitives are explained below.
TU NICAST AND PU NICAST
TUnicast and PUnicast establish a chain of references
from the base station to the node where an agent currently
is (see Figure 2). When an agent leaves a node, it leaves
behind a marker (represented by small red circles in Figure
2), indicating the next node to which it migrated. In TUnicast
these markers are temporary, they expire with time. In
PUnicast, markers are not volatile and must be explicitly
destroyed. In PUnicast additional markers are used. When
28
a mobile agent arrives at a node, a marker indicating the
previously visited node is saved, so that a reverse chain to
the base station is formed.
In PUnicast, a specific procedure exists to eliminate
circular chains of references that will no longer be used.
We will call such chains loops here. A loop is generated
when a mobile agent moves to a node that is already one
of the members of the chain of references (see Figure 3). In
this case a message is sent along the created loop to destroy
the references (this message is represented by message m
in Figure 3). Loops can also be generated in TUnicast.
However, since references are destroyed automatically with
time, no specific procedure for eliminating them is needed.
In TUnicast as well as in PUnicast, the chains are updated
whenever an agent sends a message to the base station. The
agent message contains the address of the node where it
currently is. Let us call this node reference node. When the
base station receives the message, it updates its reference
to that agent. The reference node will become now the first
node (from the base station) in the chain to the agent. In
PUnicast, when a message from the base station to the
agent arrives at the reference node, the previous chain from
the reference node to the base station is destroyed (with
a message sent backwards, from the reference node to the
base station). In TUnicast the previous chain is destroyed
automatically with time.
These primitives address each a specific type of interaction between the base station and a mobile agent. TUnicast
is useful when the mobile agent has a short-duration task
to be accomplished. In this case, the route might be valid
during the whole task execution and it is eliminated without
further action. PUnicast is useful for mobile agents which
execute long-duration tasks. For example, a mobile agent
sent in the WSN to monitor the occurrence of an occasional
event (the detection of human presence, for instance). In this
case, the route lasts for a long time, without the need for
refreshing.
Using these chains, the base station can send messages to
mobile agents. One of these messages might be a connection
establishment message. When a mobile agent receives such
a message, it no longer moves until the connection finishes.
After a connection is established, the base station and the
mobile agent can engage in higher-level forms of interaction,
such as, for example, method invocation or the establishment
of a connection for the sending of streaming data from the
mobile agent to the base station.
simultaneously in opposite directions. Consider that message
m is sent from node n1 to node n2 (during the process of
broadcasting this message) and at the same time agent ag
moves from node n2 to node n1 . If message m is discarded
at node n1 right after being sent, the agent ag might not
receive it. In MASPOT, in such a scenario, the message is
only discarded after agent ag receives the message (at node
n1 ). This is done as follows. A message is only discarded
at a node after it receives receipt acknowledgments from
the nodes to where the message was sent. In the situation
described above, node n2 only sends an acknowledgment
message to node n1 after node n1 acknowledges that the
agent was successfully received. At this time, a local copy
of message m still exists at n1 and is delivered to the agent
before being deleted.
IV. E VALUATION OF M IGRATION C OST
One of the key issues in developing a mobile agent system
to WSN is the amount of energy spent by agents during their
life cycle. This section describes the results of experiments
to evaluate the amount of energy spent by nodes during agent
migration.
The test scenario was composed of a Sun SPOT kit
version 5, which has two sensor nodes and one base station.
We created an application where a mobile agent moves
from one node to another and, while at a node, it reads
the temperature measured by the sensor node.
The experiments to evaluate the amount of energy spent
during migration were divided into two scenarios. The first
scenario includes migration of the agent code, execution
state and data state. In the second scenario, only execution
and data state were migrated, i.e., the suite used by the
agent was already installed on the destination node. The
former migration was performed using MASPOT strong
migration feature. The latter migration was performed using
the Sun SPOT Isolate migration mechanism. We repeated
the experiments with each scenario 15 times (thus we
obtained 15 samples to each scenario). The agent size was
1.81 kbytes.
The Sun SPOT platform makes available an interface,
called IBattery, which provides primitives to read the level
of the node battery. On the origin node, the battery level was
obtained at the instant when the agent requests migration to
the destination node and at the instant when the agent migration ends. On the destination node, the battery level was
obtained at the instant when the migration request arrives
and at the instant when the agent resumes its execution.
The difference between these battery levels corresponds to
the amount of enery spent at each node.
For the analysis of the results a 95% confidence level
was adopted. Since the number of samples is less than 30,
a t-Student distribution was used.
The results of the experiments are shown in
Tables I and II. For the first scenario, where MASPOT
B ROADCAST
Broadcast is a primitive that floods a message throughout
the network. Broadcasting is useful when a specific action
is to be performed by many agents.
In MASPOT, a special mechanism is implemented to
address message delivery while agents move. It avoids that a
broadcast message and a mobile agent are sent along an edge
29
Table I
AGENT M IGRATION C OST
of strong migration. We argue that this supports the viability
of using mobile agents with MASPOT in the Sun SPOT
platform. It is important to notice that we did not compare
MASPOT with MAPS and AFME since MAPS and AFME
do not provide strong migration.
Migration Cost in MiliAmpere (mA)
MASPOT Strong Migration
Isolate (Weak) Migration
Sample
Sender
Receiver
Sample
Sender
Receiver
1
0.2274
0.1976
1
0.1548
0.1261
2
0.2272
0.2007
2
0.1581
0.1260
3
0.2234
0.2006
3
0.1591
0.1253
4
0.2278
0.1959
4
0.1568
0.1259
5
0.2270
0.1975
5
0.1565
0.1254
6
0.2274
0.1970
6
0.1568
0.1249
7
0.2257
0.2073
7
0.1547
0.1236
8
0.2273
0.1971
8
0.1562
0.1265
9
0.2258
0.2002
9
0.1598
0.1253
10
0.2211
0.1963
10
0.1597
0.1274
11
0.2244
0.2016
11
0.1585
0.1262
12
0.2288
0.1998
12
0.1596
0.1268
13
0.2269
0.1972
13
0.1587
0.1277
14
0.2306
0.2007
14
0.1591
0.1243
15
0.2311
0.2010
15
0.1586
0.1251
Mean
0.2268
0.1993
Mean
0.1577
0.1257
Std.Dev.
0.0026
0.0029
Std.Dev.
0.0017
0.0011
Overall mean: 0.2130
Overall mean: 0.1417
V. R ELATED W ORK
Many mobile agent systems have been proposed, specially
for traditional distributed systems (Internet). Since the advent of Java, it became the main programming language used
for implementing mobile agent systems, since it provides
built-in functionality useful for the implementation of such
systems, such as dynamic class loading and serialization.
One of the main mobile agent systems developed in Java
for the Internet was Aglets [9].
In the context of WSNs, mobile agents have been
proposed as a means to address the need for WSN
(re)programming and for extending the network lifetime
(by conserving the energy of nodes) (e.g., [4], [5], [10]).
A number of mobile agent systems have been proposed
and implemented so far [1], [3], [5], [7], [13], [18]. Agilla
[5] and the system described in [18] were developed for
the TinyOS operating system. SensorWare [3] is based on
mobile control scripts. Smart Messages [7] implements the
migration of Java code as messages that traverse a network
and are executed on nodes. It is based on a modification
of the Java KVM virtual machine. The only mobile agent
systems for the Sun SPOT platform that we are aware of
(beyong MASPOT) are MAPS (Mobile Agent Platform for
Sun SPOTs) [1] and AFME (Agent Factory Micro Edition)
[13]. These systems are thus based on Java.
MAPS is based on components that interact via events
and each component provides services to mobile agents,
including services for agent creation, agent cloning, agent
migration, timer handling and message transmission. MAPS
does not implement migration of code. As stated in [1], an
agent can only migrate to nodes where the agent code has
been previously installed. This restriction comes from the
fact that agent migration in MAPS relies on the migration
of Isolates (that does not include code migration) [1].
AFME [13] is an agent framework originally developed
for 3G cell phones, but it was reengineered for Sun SPOT.
The AFME platform consists of a scheduler and platform
services, which include the wireless message transport and
the migration services. The wireless message transport service provides datagram-based communication between two
nodes. There is no message delivery or ordering guarantee.
The migration service provides transfer of an agent’s execution state. However, it does not provide migration of code.
Any classes required by the agent must already be present
at the destination [13].
The system we describe in this paper, MASPOT, differs
from other systems, since it is, to the best of our knowledge,
the first java-based mobile agent system for wireless sensor
Table II
M EAN P ERCENTAGE OF BATTERY U SE PER M IGRATION
(BATTERY CAPACITY: 720 M A)
Mean Percentage of
MASPOT Strong Migration
Sender
Receiver
0.0315
0.0277
Overall perc.: 0.0296
Battery Use (%)
Isolate (Weak) Migration
Sender
Receiver
0.0219
0.0175
Overall perc.: 0.0197
strong migration was used, the mean spent energy
was 0.2268 mA for the origin node, and 0.1993 mA
for the destination node. These values give an
overall mean of 0.2130 mA. The confidence interval
[0.2254; 0.2281] mA was obtained for the origin node, and
[0.1977; 0.2009] mA for the destination node.
When the Sun SPOT Isolate mechanism was used (second
scenario), the mean spent energy was 0.1577 mA for the
origin node and 0.1257 mA for the destination node, giving
an overall mean of 0.1417 mA. The confidence interval
for the origin node was [0.1568; 0.1587] mA and for the
destination node was [0.1251; 0.1263] mA.
The mean percentage of battery use is shown in Table II.
Each Sun SPOT node is equipped with a 720 mA battery.
Thus, MASPOT strong migration spent on average 0.0315%
and 0.0277%, respectively, of the origin and destination node
battery capacities. Using the Isolate mechanism, migration
spent on average 0.0219% and 0.0175%, respectively, of
the origin and of the destination battery capacities. Considering the average values obtained with these experiments,
MASPOT strong migration spent around 50.31% more energy than the Isolation migration mechanism (relative cost
due to code migration).
The mean spent energy during agent migration corresponded to 0.0296% of the total battery capacity in the case
30
networks that supports strong migration. As a result, a
mobile agent can migrate to a node that does not have its
code previously installed. Additionally, MASPOT includes
an agent management service. Adding code migration to Sun
SPOTs extends the range of possible applications of this
platform [2].
[5] C.-L. Fok, G.-C. Roman, and C. Lu. Agilla: A mobile agent
middleware for self-adaptive wireless sensor networks. ACM
Transactions on Autonomous and Adaptive Systems, 4(3), July
2009.
[6] D. Gelernter. Generative communication in linda. ACM
Transactions on Programming Languages and Systems, 7:80–
112, 1985.
VI. C ONCLUSION
[7] P. Kang, C. Borcea, G. Xu, A. Saxena, U. Kremer, and
L. Iftode. Smart messages: A distributed computing platform
for networks of embedded systems. The Computer Journal,
47(4), 2004.
This paper described MASPOT, a mobile agent system
for the Sun SPOT platform. To the best of our knowledge,
MASPOT is the first mobile agent system for this platform
that supports code migration. Supporting code migration is a
fundamental issue when considering using mobile agents to
support WSN reprogramming. The possibility of executing
mobile agents on Sun SPOTs extends considerably the range
of possible applications for this platform.
Considering using mobile agents on WSN raises an immediate question about the implied costs. We performed
specific experiments to evaluate the cost of agent migration.
The experiments showed that using mobile agents on Sun
SPOT with MASPOT is a viable solution.
Mobile agents can be used to support the management
of WSN in different ways. We plan to explore the use of
mobile agents in WSN more thoroughly, to verify in which
situations their use is more beneficial.
[8] D. B. Lange and M. Oshima. Seven good reasons for mobile
agents. Communications of the ACM, 42(3), Mar. 1999.
[9] D. B. Lange, M. Oshima, G. Karjoth, and K. Kosaka. Aglets:
Programming mobile agents in java. In Proc.of the Int.Conf.
on Worldwide Computing and Its Applications, 1997.
[10] D. Massaguer, C.-L. Fok, N. Venkatasubramanian, G.-C.
Roman, and C. Lu. Exploring sensor networks using mobile
agents. In Proc.of AAMAS’06, Hakodate, Hokkaido, Japan,
May 2006.
[11] S.
Microsystems.
http://www.sunspotworld.com.
Sun
SPOT
world.
[12] S. Microsystems. Java 2 platform, micro edition (J2ME)
- Connected Limited Device Configuration - specification version 1.1, Mar. 2003.
ACKNOWLEDGMENT
The authors would like to thank Serge Rehem (JavaBahia
Group’s leader) and Marlon Freitas for making Sun SPOT
kits available for our tests.
[13] C. Muldoon, G. M. P. O’Hare, M. J. O’Grady, and R. Tynan.
Agent migration and communication in WSNs. In Proc.
of the 9th Int.Conf. on Parallel and Distributed Computing,
Applications and Technologies, pages 425–430, 2008.
R EFERENCES
[1] F. Aiello, A. Guerrieri, and R. Gravina. Maps: A mobile agent
platform for WSNs based on java sun spots. In Proc. of the
3rd Int.Workshop on Agent Technology for Sensor Networks
(ATSN-09), Budapest, Hungary, May 2009.
[14] OMG. Mobile agent facility specification - v1.0, Jan. 2000.
[15] E. Shakshuki, X. Xing, and H. Malik. Mobile agent for
efficient routing among source nodes in wireless sensor
networks. In Proc.of the Third IEEE Int.Conf. on Autonomic
and Autonomous Systems (ICAS’07), 2007.
[2] E. Arseneau, R. B. Smith, R. Goldman, A. Poursohi, and
J. Daniels. Simplifying the development of sensor applications. In Proc.of the OOPSLA06 - ACM SIGPLAN International Conference on Object-Oriented Programming, Systems,
Languages and Applications, Portland, Oregon, USA, Oct.
2006.
[16] D. Simon, C. Cifuentes, D. Cleal, J. Daniels, and D. White.
The squawk java virtual machine: Java on the bare metal.
In Proc.of the 20th Object-Oriented Programming Systems,
Languages and Applications (OOPSLA 2005), 2005.
[3] A. Boulis, C.-C. Han, and M. B. Srivastava. Design and implementation of a framework for efficient and programmable
sensor networks. In Proc.of the 1st Int.Conf. on Mobile
systems, applications and service, 2003.
[17] D. Simon, C. Cifuentes, D. Cleal, J. Daniels, and D. White.
Java on the bare metal of wireless sensor devices - the squawk
java virtual machine. In Proc.of the ACM VEE06 - Virtual
Execution Environments, Ottawa, Canada, June 2006.
[4] M. Chen, T. Kwon, Y. Yuan, and V. C.M.Leung. Mobile agent
based wireless sensor networks. Journal of Computers, 1(1),
Apr. 2006.
[18] L. Szumel, J. LeBrun, and J. D. Owens. A mobile agent
framework for sensor networks. In Proc.of the 2nd IEEE
Workshop on Embeddeed Networked Sensors, 2005.
31