MASPOT: A Mobile Agent System for Sun SPOT

Transcription

1 2011 Tenth 10th International Symposium on Autonomous Decentralized 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 ramonp88@gmail.com, fassis@ufba.br Carlos Montez DAS - Department of Automation and Systems UFSC - Federal University of Santa Catarina Florianópolis, Brazil montez@das.ufsc.br 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. INTRODUCTION 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. 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 /11 $ IEEE DOI /ISADS

2 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. II. SUN SPOT AND SQUAWK 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. 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 ) 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. A. System Overview III. MASPOT Figure 1 illustrates the main MASPOT components. A MASPOT system is composed of a set of sensor nodes, a 26

3 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. Figure 1. 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 (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 B. Agent Implementation 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 27

4 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. TUNICAST AND PUNICAST 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

5 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. BROADCAST 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 simultaneously in opposite directions. Consider that message m is sent from node n 1 to node n 2 (during the process of broadcasting this message) and at the same time agent ag moves from node n 2 to node n 1. If message m is discarded at node n 1 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 n 1 ). 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 n 2 only sends an acknowledgment message to node n 1 after node n 1 acknowledges that the agent was successfully received. At this time, a local copy of message m still exists at n 1 and is delivered to the agent before being deleted. IV. EVALUATION OF MIGRATION COST 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 29

6 Table I AGENT MIGRATION COST Migration Cost in MiliAmpere (ma) MASPOT Strong Migration Isolate (Weak) Migration Sample Sender Receiver Sample Sender Receiver Mean Mean Std.Dev Std.Dev Overall mean: Overall mean: Table II MEAN PERCENTAGE OF BATTERY USE PER MIGRATION (BATTERY CAPACITY: 720 MA) Mean Percentage of Battery Use (%) MASPOT Strong Migration Isolate (Weak) Migration Sender Receiver Sender Receiver Overall perc.: Overall perc.: strong migration was used, the mean spent energy was ma for the origin node, and ma for the destination node. These values give an overall mean of ma. The confidence interval [0.2254; ] ma was obtained for the origin node, and [0.1977; ] ma for the destination node. When the Sun SPOT Isolate mechanism was used (second scenario), the mean spent energy was ma for the origin node and ma for the destination node, giving an overall mean of ma. The confidence interval for the origin node was [0.1568; ] ma and for the destination node was [0.1251; ] 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 % and %, respectively, of the origin and destination node battery capacities. Using the Isolate mechanism, migration spent on average % and %, 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 % of the total battery capacity in the case 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. V. RELATED WORK 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 30

7 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]. VI. CONCLUSION 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. 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. REFERENCES [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 [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 [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, [4] M. Chen, T. Kwon, Y. Yuan, and V. C.M.Leung. Mobile agent based wireless sensor networks. Journal of Computers, 1(1), Apr [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 [6] D. Gelernter. Generative communication in linda. ACM Transactions on Programming Languages and Systems, 7:80 112, [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), [8] D. B. Lange and M. Oshima. Seven good reasons for mobile agents. Communications of the ACM, 42(3), Mar [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, [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 [11] S. Microsystems. Sun SPOT world. [12] S. Microsystems. Java 2 platform, micro edition (J2ME) - Connected Limited Device Configuration - specification - version 1.1, Mar [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 , [14] OMG. Mobile agent facility specification - v1.0, Jan [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), [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), [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 [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,