|
|
| (24 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| | [[image:Agilla_model_140.jpg|right]] | | [[image:Agilla_model_140.jpg|right]] |
| | | | |
| − | '''A Mobile Agent Middleware for Wireless Sensor Networks'''
| + | Agilla is a middleware framework for wireless sensor networks that significantly increases software flexibility by integrating key aspects of the mobile agent and tuple space coordination paradigms. It was the first platform to demonstrate the feasibility and benefits of using mobile agents in wireless sensor networks, and is being used by research groups around the world. |
| | | | |
| − | Download | Documentation | Examples | Publications | Related Work | Forum
| + | Agilla is made possible by the [http://formal.cs.uiuc.edu/contessa/ ONR MURI Project CONTESSA] and the [http://www.nsf.gov/ NSF] under grant number CCR-9970939. |
| | | | |
| − | == Introduction == | + | == Links == |
| − | Agilla is a middleware that provides a mobile-agent paradigm for programming and using wireless sensor networks (WSNs) . Agilla applications consist of mobile agents that can proactively migrate their code and state across the network. Mobile agents offer more flexibility by allowing applications to control the way they spread. They can position themselves in the optimal locations for performing application-specific tasks. They can save energy by bringing computation to the data rather than requiring that the data be sent over unreliable wireless links. They can increase the utility of a WSN by constraining themselves to the specific locals that are relevant to their application's requirements (in contrast to spreading throughout an entire network), and sharing the resources of a single node, i.e., multiple mobile agents can reside on each WSN node. Other systems like [http://www.cs.berkeley.edu/%7Ejwhui/research/deluge/ Deluge] and [http://www.cs.berkeley.edu/%7Epal/mate-web/ Maté] allow in-network reprogramming. Agilla, however, goes one step further by allowing programs to control where they go and to maintain both their code and state across migrations.
| + | * [http://mobilab.wustl.edu/projects/agilla Official Agilla Website] |
| − | | |
| − | Since new agents can be injected into a pre-existing network, the network can be re-tasked. Since each agent executes autonomously and multiple agents can simultaneously run on a node, multiple applications can co-exist. Since mobile agents can move and clone, they can quickly morph an application's installation base to handle unexpected changes in an environment. There are many other [http://portal.acm.org/citation.cfm?id=298136 inherent advantages] of using mobile agents, especially in a wireless sensor network. However, there are also many challenges, the foremost being the lack of computational resources and unreliable network connectivity. Agilla is the first mobile agent middleware for WSNs that is implemented entirely in TinyOS. It has been tested on Mica2 and MicaZ motes. It abstracts away complexities associated with developing WSN applications, and provides mechanisms that overcome the challenges associated with limited resources and unreliable network communication. It demonstrates the feasibility of using mobile agents within WSNs and, furthermore, it takes the first steps at identifying a minimal set of primitives that should be provided for facilitating highly flexible WSN applications.
| |
| − | | |
| − | There are many applications of mobile agents in WSNs. Three of them include intruder detection, wildfire tracking, and cargo tracking. In intruder detection, detection agents are deployed around the perimeter of a WSN. When an intruder breaches a perimeter, the agents near the breach follow the intruder and clone themselves to form a perimeter around the intruder. Note that only the nodes next to the intruder are involved with tracking process. All other nodes are free to service other applications. In wildfire tracking, as shown in Figure 1, mobile agents swarm around a fire forming a perimeter, and dynamically adjusting it based on the movements of the fire. The algorithm for adjusting the perimeter is fully distributed, ensuring scalability. In cargo tracking, a multi-hop WSN is deployed on cargo containers. Each container has a mote that contains an electronic manifest. These motes go one step beyond RFID tags in that they can perform computation, such as monitoring sensors for intrusions or contract violations. When a ship docks, agents are deployed onto the ship's WSN. These agents scour the cargo containers identifying those that contain specific items or require inspection. Mobile agents are necessary in this case since the port authorities do not trust the code of other countries to return valid results. Also changing security levels and policies require a flexible software infrastructure, which is provided by mobile agents.
| |
| − | | |
| − | [[Image:FireDetection.jpg|left|thumb|500px|Figure 1: Wild fire tracking. (1) A fire detection agent detects fire and clones itself. The clone transforms itself into a fire tracking agent that repeatedly clones itself until a perimeter has been formed. Once formed, the agents continuously adjust the perimeter by migrating and cloning themselves. (2) A notification is sent to a fire fighter notifying him of the fire's location. (3) The fire fighter injects a guidance agent into the network that leads the fire fighter along a safe route to the fire.]]
| |
| − | | |
| − | == Motivation ==
| |
| − | | |
| − | Most WSNs are inflexible application-specific systems; they are closed-systems that provide a limited set of services for a specific pre-determined set of users. As WSNs mature and motes become more sophisticated, large-scale WSNs consisting of thousands of nodes that span vast geographic areas will be deployed for longer periods of time. The large scale of these networks will inevitably lead to them being shared by multiple users, possibly simultaneously. These users are transient; they may come and go, sporadically using the network whenever and wherever they need to. The long deployment intervals ensure that the application requirements will change mid-deployment. The existing software infrastructure for WSNs does not provide the flexibility necessary for supporting these large-scale WSNs.
| |
| − | | |
| − | Presently, most WSNs are programmed prior to deployment and, once deployed, can only be tweaked through a static set of pre-defined parameters, severely limiting the WSNs flexibility. The network is limited to run a single application, which, as WSNs are deployed for longer intervals, becomes increasingly unacceptable. Also, the application itself may not be able to adapt to unpredictable changes in user requirements; it's simply not possible for software developers to foresee all possible uses of a WSN prior deployment. This is especially so as WSNs become larger, more sophisticated, deployed for longer periods of time, and over larger areas.
| |
| − | | |
| − | == Related Work ==
| |
| − | | |
| − | The latest version of TinyOS (version 1.1.14) takes the first steps at increasing the flexibility of WSNs by including a Deluge boot loader by default. Deluge enables you to wirelessly reprogram a WSN. It floods a new ROM image over the network and re-flashes each mote's instruction memory once the entire ROM image has been delivered. Since the entire operating system and application needs to be transferred, reprogramming a network is a slow energy-consuming process. It is not a process that can be done frequently due to lack of power and wireless bandwidth. Also, since the images are flooded, the network can only run one application at a time. One benefit of using Deluge, however, is that it reprograms a network using native code; the new application runs as efficiently as if it were installed prior to the network being deployed.
| |
| − | | |
| − | Another approach to increasing WSN flexibility is through a virtual machine that facilitates the distribution of virtual-machine-specific code. The canonical example of such a system for TinyOS-based networks is Maté. Maté programs are implemented as a set of capsules of various types. Each type of capsule performs a specific function, e.g., run-once, run-periodically, send-message, receive message, or function calls. The virtual machine supports a static set of capsules, which limits the number of capsules of a particular type that a developer can use. The capsule contains a sequence of virtual-machine instructions and a version number. Whenever a new capsule is injected, Maté epidemically spreads it throughout the WSN. Like Deluge, Maté only supports one application at a time. It does not allow fine-grain control over where new capsules are propagated, nor does it allow the capsules to carry run-time state, e.g., a stack or program counter, as it moves.
| |
| − | | |
| − | == Agilla Middleware Architecture ==
| |
| − | | |
| − | The Agilla middleware architecture is shown in Figure 2. Agilla runs on top of TinyOS and allows multiple agents to execute on each node. The number of agents is variable and is determined primarily by the amount of memory available. Each agent is autonomous, but shares middleware resources with other agents in the system. Agilla provides two fundamental resources on each node: a neighbor list and a tuple space. The neighbor list contains the addresses of neighboring nodes. This is necessary for agents to decide where they want to move or clone to next. The tuple space provides an elegant decoupled-style of communication between agents. It is a shared memory architecture that is addressed by field-matching rather than memory addresses. A tuple is a sequence of typed data objects that is inserted into the tuple space. The tuple is remains in the tuple space even if the agent that inserted it dies or moves away. Later, another agent may retrieve the tuple by issuing a query for a tuple with the same sequence of fields. Note that tuple spaces decouples the sending agent from the receiving agent: they do not have to be co-located, or even aware of each other's existence, for them to communicate.
| |
| − | [[image:agillaArch.jpg|right|thumb|Figure 2: The Agilla Middleware Architecture]]
| |
