performance, flexibility, scalability, and support of federated services across sensor groups in sensor networks. The APPA enables dynamic self-configuration of ...
Adaptive Peer-to-Peer Agent Sensor Networks Ray-Yuan Sheu, PhD, Michael Czajkowski, and Martin Hofmann, PhD Lockheed Martin Advanced Technology Laboratories Cherry Hill, NJ 08002, USA 886-856-792-{9057, 9792, 9711}
{rsheu, mczajkowski, mhofmann }@atl.lmco.com ABSTRACT We present an agent-based, adaptive peer-to-peer, hybrid architectural approach for sensor networks to address some of the challenges and needs presented in net-centric, field-deployed, or soldier-walk-and-drop ad-hoc sensor networks. The proposed Adaptive Peer-to-Peer Agent Architecture (APPA) combines the benefits of adaptive peer-to-peer, agent-based, and serviceoriented architectures to address the survivability, robustness, performance, flexibility, scalability, and support of federated services across sensor groups in sensor networks. The APPA enables dynamic self-configuration of independent, but cooperating agents. These agents work as service proxies for sensors to proactively use each others’ agent context information to cooperate and coordinate sensors for task allocations and task or agent migration using its mobile and agent architecture. The intended goal is to meet some of the unique challenges as anticipated in a dynamic, small-team echelon in battlefield. The purpose is to provide context-driven situational awareness to help command and control commanders in decision-making. The APPA is built on Lockheed Martin Advanced Technology Laboratories’ previously proven mobile agent technology and extended with peer-to-peer capability, service-oriented architecture, and recent advances in market-based team formation and Distributed Constraint Optimization Problem (DCOP) [17, 18, 20, 22].
Categories and Subject Descriptors D.3.3 [Computer-Communication Networks]: Distributed applications – Distributed adaptive peer-to-peer agent-based architecture, SOA architecture, market-oriented adaptive task allocation for resource sharing, grouping, and teaming, ad-hoc sensor networks, distributed data redundancy, information replication.
1. INTRODUCTION Lockheed Martin Advanced Technology Laboratories (LM ATL) envisions the use of tactical sensor networks as a means to increase situational awareness of small unit commanders and, thus, to improve the quality of their decisions. In this paper, we identify some of the important technical challenges to realizing effective and operationally suitable distributed, ad-hoc sensor networks, and we describe an architecture that facilitates configuring such networks In distributed operations, with ever-advancing sensor technologies, often network-enabled wired or wireless sensors are dynamically deployed as needed for a mission. Some of the sensors are designed to be stationary and others are only used for certain tasks with predetermined, short operational life. During tactical operations, new sensors might be added into the existing
field-deployed sensor networks. Hence, dynamic inserting and deleting of sensors is typical for command and control (C2) fielddeployed sensor networks. In addition, the variations of sensor types and capabilities further compound the challenges of trying to optimize the benefit of the overall mission beyond individual unit or team or to maximize the sensor resource sharing among those ad-hoc, peer-to-peer, heterogeneous sensors. It is also not feasible to pre-plan the task and resource sharing before executing a mission because aspects of the mission will need to be dynamically evolved as needed per C2 commander decision or unexpected (pop-up) events. Another main challenge for ad-hoc sensor networks is that sensors often need to be re-tasked to support multiple warfighters. For example, often times a sensor is re-tasked with operational cues that provide latitude, longitude, altitude, and azimuth for capturing video surveillance information for some tactical unit requiring decision support. Thus, it is desirable to be able to dynamically re-task a networked sensor to maximize the sensor’s usefulness. Also, it is often desirable to task an already-tasked sensor agent (so called busy agent) with additional tasks because there is no conflict with existing assigned tasks. In tactical field operation, any dynamically-deployed sensor node, independent of size and capability, is expected to suffer a communication problem such as fluctuation in bandwidth, lost communications, loss of capability, or destroyed sensor agent (node). These problems could sometimes cause costly mistakes in C2 decisions and dire consequence in tactical warfighting. Therefore, accommodating unreliable and unstable communications among the deployed sensors is important for effective missions. Also, for C2 field-deployed sensors, it is not feasible to deploy heavy duty large servers to support peer-to-peer sensors and networks. Teaming (grouping) of sensors is an important feature for such tactical networks. Combining sensors should be done to increase sensor agility and adaptivity in supporting the best resource coverage and sharing to benefit multiple small unit commanders. Automatic peer-to-peer discovery and integration of sensors nodes in the reachable network neighborhood enables this capability. Beyond discovery and integration, another important feature for field-deployed sensors is to leverage each other to achieve some level of information sharing. For example, one or multiple sensor nodes might be destroyed and the rest of nodes within the same group might designate other suitable sensors autonomously to resume the coverage or sensor service whenever possible. This may require the surviving agent-based sensor nodes to be in collaboration physically and proactively move to the adaptive capability within ad-hoc, field-deployed sensor nodes as a tactical group or team is strongly tied to the sustainability and
survivability of tactical missions. Additionally, information sharing can effectively provide redundancy of sensor capabilities without having to store large amounts of data at every node.
points. We use both proxy and mobile agents to broker the discovery and communications so that collaboration can be done peer-to-peer.
To support the adaptive behavior among the agent-based sensor nodes, peer-to-peer dynamic discovery capability is important for all the participating sensor nodes to achieve teaming over unreliable communication networks. This allows the rest of the sensors in the network to take proper recovery action including moving to new locations when one or multiple sensor nodes within the sensor group loses communication contact or is destroyed. This adaptive cooperative action is done autonomously without the need of human intervention, which could potentially disrupting the mission.
In [5], it was shown that data mining in distributed networks has certain challenges since recent computationally intensive algorithms must now be adapted to a widely distributed network that [16] proposes. Our approach addresses the issues of data redundancy, efficiency, and replication throughout a sensor network through peer-to-peer cache data replication across all peer agents. One goal of ours is to support this type of work so that data mining, data filtration, and monitoring can be done thereby minimizing the probability of overloading sensor caches and taxing bandwidth.
Further, in C2 operations, users or agents should be able to remotely across the boundary of sensor groups to request for services (e.g., cue for global positioning systems [GPS] locations of a soldiers or image of certain GPS locations). It is not feasible for all users or agents to provide exponentially many-to-many communications to go through soliciting, discovery, and negotiation of requesting such services. APPA is designed to leverage the same concept as telecommunication Signaling System 7 (SS7) intelligent networks [2, 4] with hierarchical organizations and peer groups in addressing large-scale service discovery and negotiations combining with semantic-based mobile and proxy agent framework and Service Oriented Architecture (SOA) in enterprise applications. This concept allows APPA to bridge the gaps from ad-hoc micro-architectures —the adaptive peer-to-peer sensor networks—to large-scale, enterprise, back-office architectures from which the C2 users (e.g., commanders) can have direct access to the remote peer-topeer, on-demand sensor services.
The research in distributed agent collaboration has evolved from the early stage of logic specification-based agent interactions (e.g. [24]) to semantic-based agent collaboration (e.g., [23]). Our proposed agent-based approach for sensor networks will focus on semantic-based collaboration.
2. BACKGROUND Sensor networks have been the domain of many research topics [15] in the areas of distributed networks, unreliable communications handling, and autonomy. For sensor networks, data can be processed in two ways, either collect all of the reports into one server and apply algorithmic processing, or share that processing across the network distribution. Originally, the former was considered most feasible, but it has been shown [16] the latter is indeed promising. We address the problem using context-driven strategy to minimize the information across the networks and network-aware delivery mechanism. So, only the needed information is delivered with pre-processing locally in a sensor node when possible. Our approach uses highly distributed agents to follow this practice by applying real-time clustering algorithms. To do such processing, we have to overcome the issues of unreliable communication handling of sensor networks.
3. AGENT ARCHITECTURE The APPA framework is a proposed extension to LM ATL existing agent framework EMAA (Extensible Mobile Agent Architecture) [14], which has been deployed to many military applications. The major difference of APPA from EMMA is that the extension is designed to support the specific needs as anticipated in the ad-hoc, peer-to-peer, agent-based applications such as field-deployed sensor networks. Core EMAA technology provides a family of software libraries that enable the creation and deployment of robust and reliable distributed agent integration solutions. EMAA was developed to maturity by LM ATL in 1996 and was used in the US Navy Fleet Battle Experiment series as a human aiding tool. Since then, experimentation with prototypes in military exercises has guided our research and development towards the APPA architecture extension. EMAA consists of three primary types of components: docks, agents, and services (see Figure 1). The dock serves as the operating environment where the agents perform their tasking on a particular host. To gain access to its services, an agent must be received and authenticated by the dock. Each dock relies on four basic components in realizing the agent operating environment: the Agent Manager, Service Manager, Event Manager, and Agent Transporter. The Agent Manager provides thread access and scheduling services for the agents at the dock. The Service
In [9], it was shown that sensor nodes can track activities and detect problems that occur when handling and distributing information through context awareness. The architecture outlined in this paper relies not only on such awareness but also on using agents to adapt the behaviors of the entire sensor network should a fault be detected. Peer-to-peer discovery of sensors and devices on a network is the critical foundation of inter-sensor collaboration. Service discovery in sensor networks has been shown to be distributive [11]. Our architecture follows this approach by having two types of registries that can maintain context and sensor interface end-
Figure 1. EMAA Agents, Docks, Services and Mobility
Manager provides lookup and access to services installed within the dock. The Event Manager provides an asynchronous, eventbased, communication mechanism for use by any component within the dock. The Agent Transporter handles the transmission of agents to and from a dock. Our proposed approach consists of the following key agent capabilities: • An Ad-hoc, Peer-to-Peer Framework • Agent Service Wrappers for Sensors • A Composable Agent Framework • Peer-to-Peer Discovery and Agent Collaboration • Mobile and Proxy Agents
3.1 Ad-hoc Peer-to-Peer Framework In an ad-hoc, peer-to-peer agent environment, there is no common known server such as a directory server node running in some back-end C2 commander center. APPA’s extension to EMAA will eliminate the need for an EMAA service to do directory management. The agents within the same peer-to-peer network will have to be equipped with the capability to autonomously discover each other and detect if any of its peer member agents have dropped out. With the discovery and detection capability among the peer agents, the intelligent agents within the peer-topeer sensor networks will be able to autonomously collaborate and coordinate with one other. The goal is to provide sensor resource sharing and teaming to assist C2 units in better decision support for a tactical warfighter. To provide this capability, APPA’s agents are “intelligent” agents. An intelligent agent is defined as a persistent software process that is able to interact with its environment to perform tasks on behalf of a user or sensor device. An intelligent agent has the following three key characteristics:
• The agent is autonomous because it is given a set of instructions to perform without direct control of a human operator.
• In addition, the agent is adaptive because it is able to adjust what it will do based on its environment.
• Finally, the agent is cooperative because it can work together with other agents or with a human operator to accomplish its goals. Given these capabilities, our agents will be able to perform in an ad-hoc peer-to-peer environment.
3.2 Agent Service Wrapper for Sensor One of the main challenges is to enable non-agent-based sensors to participate in agent-based sensor networks, given that different sensors may have different controls and interfaces. Our approach is to use an agent-based service wrapper for a sensor as a proxy for the management of the sensor’s context, states, capability, operations, and status. The proxy agents for sensors in our architecture should not only be state-full services but also provide proactive actions on behalf of the underneath sensors. That is, agents should allow one another persistent queries for information. For example, a persistent agent-to-agent query might be: “whenever there is an unidentified object flying into a predefined geo-coordinates box, please notify me.” Without the use of the agent service wrapper to enable the underneath sensor, persistent queries are not easy to achieve.
Another main concept of the agent service wrapper is to provide a generic, peer-to-peer negotiation interface pattern and template. This allows sensor developers to simply fill-in the callback hooks with sensor specific states, capabilities, and run-time information. The proposed architecture will have the implemented protocol engines for every service agent representing the sensor.
3.3 Composable Agent Framework LM ATL’s intelligent agents are highly configurable and composable, following a workflow model described in [14]. Workflows model an agent’s process as a non-deterministic, finite state machine where “tasks” represent states, “paths” represent transitions, and the workflow is the state machine. When a service agent recognizes a change in the context of its sensor, it dynamically recomposes its workflow following expertise captured in a rule-engine. Dynamic (run-time) composition allows the service agent to immediately exhibit new behaviors when the context of its represented sensor changes. The rules are used to guide the dynamic composition process to pick the right tasks to execute given the new situation. For instance, should the sensor change its behavior to “tracking a vehicle,” rules might recompose the agent to start collaborating with other sensors in the area that assist in its tracking task. To encapsulate the right rules for the right compositions, LM ATL interviews military subject matter experts to understand what our military users need in a given situation.
3.4 Agent Mobility An agent system consists of one or more machines that contain an EMAA dock that manages when an agent is launched. When the dock launches an agent, it determines where its workflow tasks need to run and, if necessary, the agent migrates to another dock. During the execution of the agent system, agents can detect whether it would be more efficient to run their processing on different network nodes and, if so, will migrate automatically to perform load-balancing optimizations across the network. This activity is critical to sensor networks because often times there are limited bandwidth and processing capabilities on the sensor’s node or local LAN. Thus, the service agent that represents the sensor may execute wherever the network deems as most efficient, thus minimizing how much bandwidth and processing power the agent requires of the actual sensor.
3.5 Peer-to-Peer Automatic Discovery Service agents representing sensors publish themselves to two types of registries. The first is a context registry that dynamically captures the contexts of all sensors everywhere on the network. Service agents continually publish contexts to the context registry so that all services running on the network (including other service agents) can discover the context of any given sensor. Additionally, service agents register the sensor in a service registry that uses open-standards such as the Web Service Description Language (WSDL) [6] and Universal Description, Discovery, and Integration (UDDI) [3]. The service registry allows components of the architecture to discover and access sensors anywhere, providing automatic integration through a universal interface. Discovery of what a sensor can do and its constraints is guided by descriptions written in the Web Ontology Language (OWL) [21]. Such a process, called “match-making” [23], has been proven successful in our agent-based integration efforts, first starting in [8]. When applying match-making to a
sensor network, service agents can automatically discover one another and ask each other to perform tasks peer-to-peer.
3.6 Peer-to-Peer Collaboration Discovery and integration of sensors is the foundation of peer-topeer collaboration. LM ATL’s intelligent agent architecture allows an agent to collaborate with other agents and users to accomplish goals. Agent collaboration was first started at LM ATL in 1998 with [13]. Collaboration is performed following a messaging protocol of requests for service, subscriptions for future data publishing (pub/sub), querying to understand a service’s capabilities, and invitations for proposals. By following the protocol, service agents interact with one another using predetermined dialog rules. This approach empowers the service agent to govern the types of requests it should accept or reject. Service agents are allowed to make decisions based on factors such as security authorization, priority, and resource availability. Given this power, service agents can task one another and communicate peer-to-peer. The result is a network of sensor nodes that collaborates based on priority C2 requests following appropriate security measures without overtaxing limited resources.
4. APPROACH This approach describes the capabilities of APPA as it applies to sensor networks.
4.1 Agent Service Wrapper The Agent Service Wrapper (see Figure 2) is a component in the proposed architecture that enables the sensors to collaborate with other agents and achieve the larger task of sensor aggregation.
Figure 3. Architecture for Agent Service Wrapper Interface • Common Ontology for Sensors: The standard XML message will carry the payload data represented in specific ontology sets (e.g., sensor capability, sensor control) and cue operation, agent context, location context, subscription context, etc. We allow extensions to this ontology for sensor specific functionality. The agent service wrapper has a dual interface layer of subcomponents: the Agent Service interface and the Service-Oriented Architecture (SOA) Service interface. Together these two interfaces will provide agents with two-way access in both worlds, namely, the agent architecture and SOA platform. The agent will have the capability to access to the non-agent services (i.e., a fusion service running on an external SOA web platform). This capability will enable the agent-based service composability to expand beyond just the agent-enabled sensors to achieve wider use of available resources and sensors. To minimize the repeated customization efforts when integrating with a sensor, our approach provides a standard template code for target languages, which includes state machine engines to interact with our Service Wrapper Interface. The customized efforts are reduced to implement the callback details to connect with the sensor API in specific programming environment.
4.2 SOA-Capable Agent Service Wrapper
Figure 2. Agent Service Wrapper for Sensors The Service Wrapper Interface (see Figure 3) governs the interaction with the underlying sensor node device and an APPA/EMAA agent. One of the main challenges to design the agent service wrapper interface is to reduce the integration time and effort of gluing the interfaces between the agent interface and the existing sensor services or nodes. We address this challenge in the following combined aspects: • XML-based Message Specifications: The XML specification defines the message format for all the agents to abide. We use the concept of conversation sessions and unique message identifiers combined with protocol specifications to allow agents to manage the service a multi-threaded, run-time environment.
SOA services have been gaining more support in sensor applications. The agent service wrapper will support SOAs in two ways. First, the agent-enabled sensor can dynamically publish its services into SOA platform to allow other non-agent SOA service clients to access this sensor service. The second is that the agent service wrapper will leverage its dynamic service composability (discussed in Section 3.3) to automatically query the SOA service directory to find potential matching SOA services when there is a need to delegate the agent’s workload to other sensors to achieve the C2 mission objectives. Once the external SOA service provides the results, the initiator agent will compose the results, process it into the final results, and send it out to the original requesting agent. The following diagram (see Figure 4) shows how our proposed approach provides the SOA service to external SOA clients. The agent service wrapper can dynamically publish its services into the SOA platform and also dynamically retract the service by removing its service registration from the SOA directory server.
4.3 Adaptive Peer-to-Peer Sensor Networks For field-deployed sensors, three important capabilities are needed to support peer-to-peer sensors.
agent-based approach to be able to interact with the existing SOAbased sensor networks or related fusion services. Our proposed approach combines the agent-based sensor networks with SOA-based services together to provide seamless integration. Our agent-based nodes (e.g., sensors or services) will be able to go outside the agent framework to request standard SOA services and obtain the results to be aggregated and then delivered to the initiator agents for further processing. On the other hand, external SOA clients should be able to come in our agent framework via the SOA platform to request service from our agent-enabled sensors. Relatively speaking, SOA services of our agent-enabled sensors will only allow a subset of features from the agent service wrapper since our agents can maintain the service context and state, as discussed in the next section. Figure 4. Agent Service Wrapper Supporting SOA Platform
4.3.1 Autonomous Peer Discovery Autonomous Peer Discovery will enable the peer agents to mutually discover each other whenever a new peer agent joins the existing peer group if the communication protocol is compatible and network interface among the group is reachable. For this, we are assuming that the security and authentication already have been verified and validated. In this paper, we will limit our discussion in the capability of autonomous peer discovery. In the future, we will do work to address the overall security and authentication issues since in tactical warfighting the security of communication and networks is important to prevent digital jamming and hacking. 4.3.2 Autonomous Detection of Lost Peers Autonomous Detection of Lost Peers will enable the peer agents to be notified instantly whenever one of their peer agents disappeared from the peer group (or teaming) so that the survival peer agents will form a new instance of a group. At that point, the newly formed group of sensors can perform autonomous collaboration and resource management among the peer sensor agents.
4.3.3 Adaptive Peer-to-Peer Agents To achieve the adaptive, peer-to-peer, agent-based sensor networks, our approach has three steps. First, we create an agentbased service wrapper to standardize the process of enabling those non-agent-based sensors. Then, we define a set of standard message specifications defined in XML and OWL-S to allow sensors to register themselves dynamically into the distributed replicated in-memory registry. When an agent-enabled sensor node is reachable within the peer-to-peer sensor networks, it will adaptively join the existing sensor group after the automatic discovery and then register itself into the agent match-maker registry with its context, state, capability, and availability. After the registration, the newly registered agent will autonomously update its dynamic state variables, such as location or resources, whenever the state changes exceeding its threshold as defined in its context.
4.4 Hybrid Agent Framework Many sensor manufactures or sensor networks already support the emerging standards, service-oriented architecture (SOA), hosted in standard web service platform. Further, many sensors’ related applications, such as fusion applications or fuselet as in Joint Battlespace Information (JBI) applications, have widely supported SOAs as the common interface for integration among heterogeneous services. Hence, it is important for our proposed
4.5 Context-Driven Situation Awareness Every sensor on the network is represented by a service agent. This agent acts on behalf of the sensor by performing actions based on the sensor’s context. A context is defined as a sensor’s current state (i.e., power is on, maximum range is 2 km, frequency is 10 Hz) and its behavior (i.e., “tracking a vehicle,” “performing bomb damage assessment”). As the context of a sensor changes, the service agent performs different tasks based on a new state or behavior. We call this context-driven situation awareness. For example, if there is a degradation in the maximum range of the sensor, the service agent will inform other sensor agents, operational units, and C2 commanders of the new limitations. This in turn will affect when and how this sensor may be used by other components in the architecture, causing a ripple effect of behavior changes throughout the network to make up for the sensor’s new context. Situation understanding and health monitoring of the entire sensor network follow by analyzing all of the contexts of the sensors as they change. The proposed approach supports the concept of context-driven behaviors for sensors. In tactical operations, it is necessary to support the context-driven service since the request for service is highly dependent upon the context that the requestor situation and current sensor state and location. Hence, supporting the dynamic update of agent’s context is an important feature to be supported by the proposed architecture in peer-to-peer sensor networks. We define a publish-subscribe (pub-sub) collaboration protocol for supporting the dynamic context update and asynchronous event notification mechanism. The pub-sub collaboration among the agents will allow an initiator agent to request for a persistent notification service when the requesting “context” criteria are matched. When the servicing agent needs to delegate the service to another suitable agent to continue providing the pub-sub service, our agent framework uses its mobility capability to migrate the service from one service agent to another with the latest context of the pub-sub request. The persistence and flexibility is strongly related to the survivability of the peer-topeer sensor networks for tactical missions. With the support of autonomous discovery and detection capabilities from the architecture, pub-sub collaboration among the peer agents is made possible through context sharing. Context sharing persists even when the sensor of the service agent is lost by providing a new context behavior of “lost communication.” Or, when a new sensor agent joins the peer group and it can provide better service, the persistent context subscription can be autonomously transfer to the new sensor agent and free up the current sensor agent for other tasks.
4.6 Collaboration Protocols To enable agents to cooperate and collaborate with each other, we designed six major protocols and various message types with the flexibility to allow each agent from autonomous registration with peer-to-peer network information and service capabilities to dynamically request service provided by other sensor agents. We further defined a set of ontology and semantic set to allow sensor agents to exchange and query against replicated service registry. When connected with back-end C2 enterprise servers, sensor agents will be able to publish available services dynamically and request services outside the sensor group boundary. The protocols are designed to support internal and external cooperation and collaboration. • Admin Protocol • Register Protocol • Query Protocol • Pub-Sub Protocol • Request-For-Service Protocol • Invite-For-Proposal Protocol Admin protocol is used to manage agents remotely including migration, cloning, aggregation (composition), and life-cycle management. Registering protocol allows an agent to register itself about its static context (e.g., dependency, constraints, profile, capabilities) and dynamic context (e.g., location, wellness, mission, task assignment). And it will also allow an agent to dynamically register a new available service or deregister its service. Pub-Sub protocol enables one agent to dynamically subscribe an event from another agent which currently is producing the interested event. Request-for-Service protocol allows an agent to negotiate whether a service can be provided by another agent. Invite-for-Proposal protocol allows one agent to send out invitations for teaming to achieve a common task considering the team will create a larger benefit for the participating agents or the hosting group.
4.7 Reliability, Efficiency, and Fault Tolerance When there is a communication problem or if an agent-based sensor node is destroyed, our proposed approach will autonomously form a survival group depending upon the communication with the peer agents. As shown below (see Figure 5), first an agent is destroyed, and then communication is split due to connectivity breakdown detected by our agent framework. The
result is that two new agent groups will be formed. The new groups will individually and autonomously create new collaboration among themselves within each group boundary. They will also continue to provide services to the SOA if it is still possible to do so.
4.8 Data Replication and Redundancy In peer-to-peer agent environment, there is no guarantee that a dedicated platform server (e.g., registry server) can survive the mission until the end. It is possible that even with multiple replicated servers, there is still a good probability that all the replicated servers may be destroyed. If this happens, the peer agent registration information is lost, and the agents will have to know about this when it is happening. Once that happens, the agents will have to explicitly discover each other on their own. This is not a feasible solution to peer-to-peer agent environment. Our proposed architecture supports data replication as in-memory cache across the agents. This cache is not intended for replicating large objects such as video or other large binary data. It is designed for storing agent registration information, user context, agent context, and sensor context (e.g., capabilities, ontology sets), states, locations, and other small data set. With this data replication capability for all peer sensor agents, the registry information is always available to all the peer agents. The target of APPA scalability is twofold. First, for a group of sensor nodes, we anticipate the size should be less than 10 to 20 nodes. This is genetic limitation from the low-end managed network routers or switches and the constraint of replication among all the sensor agents within the same group. The second aspect of scalability is that APPA is designed to support largescale of sensor nodes using the similar concepts of telecommunication SS7 Intelligent Networks [2, 4] in applying distributed partition and hierarchical organizations and peer groups for service discovery and negotiations. In all, APPA only replicates a relatively small amount of data across all the nodes within the same sensor group with the hierarchical organization strategy for aggregating a large amount of groups. Combining these two architectural approaches, APPA will support very large-scale sensor networks.
4.9 Market-Oriented Approach In distributed sensor networks, the challenge of dynamically allocating the most appropriate sensor resource for a given new task is active research (e.g., Distributed Constraint Optimization Problem (DCOP) [17, 18, 20, 22], ADOPT [1], etc.). In our proposed approach, our agent framework currently supports three different variations of market-oriented sensor management for resource allocations, namely, simple distributed auction [10], combinatorial auction [7], and CLUstering for Self-Synchronizing Tasked Agent Reallocation (CLUS-STAR) allocation algorithms [12].
Figure 5. Fault Tolerance during Communication Breakdown
In previous work done at LM ATL, (CLUS-STAR [12]) we demonstrated a novel hybrid approach that uses market-oriented negotiation methods similar to a combinatorial auction but extends winner determination with a polynomial-time constrained clustering algorithm, called CLUS-STAR that is able to reassign agents to accommodate new tasks that come up without dropping existing tasks. CLUS-STAR is able to fulfill all needs for new and existing tasks more often than a combinatorial auction approach when many of the agents are already tasked, while also decreasing
the cost of the tasks. CLUS-STAR can also be used for team or coalition formation problems. Currently, we use CLUS-STAR as the default resource allocation engine in our approach to peer-topeer sensor networks.
5. CONCLUSION In this paper, we have presented a novel, adaptive, peer-to-peer hybrid architectural approach to address some of the challenges in field-deployed, ad-hoc sensor networks. The adaptive architecture—Adaptive Peer-to-Peer Agent framework (APPA)— is specifically targeting some of the main challenges anticipated in the tactical warfighting environment with field-deployed tactical sensors. This architecture will support the sustainability and survivability of context-driven, agent-based sensors in ad-hoc, distributed networks for sharing sensor resources. This approach will not only support the ad-hoc teaming but also achieve the needed performance and dynamic scalability.
6. FUTURE WORK We have introduced the proposed approach including APPA/EMAA agent framework into several Lockheed Martin research and development projects. LM ATL is currently building an implementation of APPA for an internal project. While the specifics of how APPA is being constructed are proprietary, we will be using the following techniques: • XML-based agent collaboration protocol. Agents follow an XML message passing schema that well defines their state-full communication. • Semantic context descriptions using OWL [21] ontologies. • Describing Agent Service Wrappers using OWL-S [19]. • Application of ADOPT [1] algorithms for agent task allocation. • Self-adaptation of Agents using various machine learning algorithms. Once constructed, LM ATL will apply the technology to real sensors and weapons systems. The goal is to improve coordination and planning of warfighters at every level. To that end, every sensor, weapon, and user interface will have a service agent assigned to assist the component by interacting with other agents and services available on the network. Following this deployment, the agents could perform various new capabilities such as: • Context-Based Persistent Query: An agent sets up a query with a context registry (see Section 4.5) to see if other sensors or weapons come within range to provide assistance. As an example, consider a warfighter who is interested in taking aerial photos of a certain location. When a helicopter moves within range on an unrelated mission, its camera could take that photo. The persistent query notifies the warfighter’s service agent so it can begin collaboration with the camera’s service agent to request its service. • Automated C2 Assistance: Many times, too much information is presented to the commander resulting in poor decisions. Our architecture can inform a commander only when important decisions must be made with their approval. For example, a service agent representing a task force of marines may suddenly need air support. Through this context change, the service agent knows to query for available blue force assets, listing them to a commander with priority emphasized on the most available and closest asset.
Our proposed architecture to enable sensor networks and warfighters to coordinate and plan in more meaningful way holds great potential. We look forward to providing the next-generation of warfighters with new capabilities to be better informed, smarter, and safer.
7. ACKNOWLEDGMENTS Our thanks are owed to TACSAS development team and C2 Assistant team, Steve Blackmon and Angie Chappell, in contribution of this proposed approach. Much thanks to our architecture advocator Angela Pawlowski for her diligence. Special thanks to our program sponsor management teams in Lockheed Missile and Fire Control, Orlando and Texas, USA.
8. REFERENCES [1] Ali, S. M., Koenig, S., Tambe, M. Preprocessing Techniques for Accelerating the DCOP Algorithm ADOPT. In Proceedings of the 4th International Conference on Autonomous Agents and Multiagent Systems (AAMAS). Utrecht, The Netherlands, July, 2005 [2] Bahl, M., Daane, J., Oapos, Grady, R., Evolving intelligent interexchange network-an SS7 perspective. In Proceedings of the IEEE, Vol. 80, Issue 4, April 1992, 637 – 643. [3] Bellwood, T., Universal Description, Discovery and Integration http://uddi.org/pubs/ProgrammersAPI_v2.htm., 2002. [4] Black U. D., ISDN and SS7: Architectures for Digital Signaling Networks. Prentice-Hall Advanced Communications Series, ISBN:0-13-259193-6, 1997 [5] Cantoni, V., Lombardi, L., Lombardi, P. Challenges for Data Mining in Distributed Sensor Networks. In Proceedings of the 18th International Conference on Pattern Recognition (ICPR’06). Hong Kong, China, August 20-24, 2006, 1000-1007. [6] Christensen, E., Curbera, F., Meredith, G., Weerawarana, S., Web Services Description Language (WSDL) 1.1. http://www.w3.org/TR/wsdl, 2001. [7] Cramton, P., Shoham, Y., Steinberg, R. Combinatorial Auctions, MIT Press. January 2006, ISBN-10: 0-262-03342-9. [8] Czajkowski, M., Buczak, A., Hofmann, M. Dynamic Agent Composition from Semantic Web Services. In Proceedings of 2nd International Workshop on Semantic Web and Databases (SWDB’04). Toronto, Ontario, Canada, July 2004. [9] Evers, L., Bijl, M.J.J., Marin-Perianu, M., Marin-Perianu, R.S., Havinga, P.J.M. Wireless Sensor Networks and Beyond: A Case Study on Transport and Logistics. Technical Report TRCTIT-05-26 Centre for Telematics and Information Technology, University of Twente, Enschede. ISSN 1381-3625, 2005. [10] Ezhilchelvan, P. and Morgan, G. A Dependable Distributed Auction System: Architecture and an Implementation Framework. In Proceedings of the Fifth international Symposium on Autonomous Decentralized Systems (ISADS). IEEE Computer Society, Washington, DC. 3 [11] Frank, C., Handziski, V., Karl, H. Consistency Challenges of Service Discovery in Mobile Ad Hoc Networks. In Proceedings of the 7th ACM International Symposium on Modeling, Analysis and Simulation of Wireless and Mobile Systems (MSWiM 2004). Venice, Italy, October, 2004, 105-114.
[12] Greene, K., and Hofmann, M. O., Coordinating Busy Agents Using a Hybrid Clustering-Auction Approach, AAAI Workshop, Auction Mechanisms for Robot Coordination, held in conjunction with The Twenty-First National Conference on Artificial Intelligence - AAAI 2006, July 17, 2006, Boston, Massachusetts, U.S.A. [13] Kay, J., Etzl, J., Rao, G., Theis, J. The ATL Postmaster: A System for Agent collaboration and Information Dissemination. In Proceedings of 2nd International Conference on Autonomous Agents (Agents’98). Minneapolis/St. Paul, Minnesota. May 9-13, 1998. [14] Hofmann, M. O., Chacon, D., Mayer, G., Whitebread, K., and Hendler, J. Cast Agents: Network-Centric Fires Unleashed. In Proceedings of National Fire Control Symposium. Lihue, Kauai, Hawaii, 2001, 12–30. [15] Lesser, V., Ortiz Jr., C. L.; Tambe, M. (Eds.), Distributed Sensor Networks, A Multiagent Perspective Series: Multiagent Systems, Artificial Societies, and Simulated Organizations , Vol. 9, 2003, 386 p., ISBN: 978-1-4020-749 [16] Ji, X., and Zha., H., Sensor Positioning in Wireless Ad-hoc Sensor Networks with Multidimensional Scaling. In Proceedings of IEEE INFOCOM 2004. Hong Kong, China, 2004, 2652-2661 [17] Maheswaran, R. T., Tambe, M., Bowring, E., Pearce, J., and Varakantham., P. Taking DCOP to the Real World: Efficient Complete Solutions for Distributed Event Scheduling. In Proceedings of the 3rd International Joint Conference on Agents and Multi Agent Systems (AAMAS-2004). New York City, New York, July 19-23 2004.
[18] Mailler, R. and Lesser, V., Solving distributed constraint optimization problems using cooperative mediation. In Proceedings of the 3rd International Joint Conference on Agents and Multi Agent Systems (AAMAS-2004), New York City, New York, July 19-23 2004. [19] Martin, D., et al. Web Ontology Language Services (OWL-S) 1.1, http://www.daml.org/services/owl-s/1.1., 2005. [20] Modi, P. J., Shen, W.-M, Tame, M., and Yokoo, M., ADOPT: Asynchronous distributed constraint optimization with quality guarantees. In Artificial Intelligence Journal, 161:149 180, 2005. [21] McGuinness, D., van Harmelen, F., Web Ontology Language (OWL), http://www.w3.org/TR/owl-features/, 2004. [22] Petcu, A. and Faltings, B., A scalable method for multiagent constraint optimization. In Proceedings of International Joint Conferences on Artificial Intelligence (IJCAI-05), Edinburgh, Scotland, Aug. 2005. [23] Sycara, K., Paolucci, M., Ankolekar, A. Srinivasan, N. Automated Discovery, Interaction and Composition of Semantic Web services. In Journal of Web Semantics, Vol. 1, Iss. 1, September, 2003, 27-46. [24] Tasi, J. P. and Sheu, R.-Y.: A Distributed Cooperative Agents Architecture for Software Development. The Next Generation of Information Systems 1991: 271-290.
