Agents in Ad Hoc Environments
A Whitepaper
Version: 0.C
Abstract: Mobile adhoc computing environments are a currently upcoming and very exiting and promising agent application area. Examples can be found in office or meeting environments or when people are passing shops or other people in the street. FIPA recognized the big potential of adhoc computing and has created a Technical Committee “Adhoc” in February 2002 with the mission to develop solutions enabling agents to interoperate in mobile adhoc environments.
Currently the TC is writing that whitepaper in order to collect and structure all technical contributions received. Based on that whitepaper, the TC will come up with a first draft of a preliminary specification.
If you are interested in participating in that work, please contact the TC-Chair Michael Berger (m.berger@siemens.com) or the co-chair Heikki Helin (heikki.j.helin@sonera.com). Information can also be found on our website http://www.fipa.org/activities/ad_hoc.html.
Editor: Michael Berger
Document History:
|
Version |
Date |
Author |
Change |
|
0.A |
04/07/02 |
Michael Berger |
Template |
|
|
22/07/02 |
Michael Watzke, Michael Berger |
Added overview of Jini and UpnP in Section 2 Added Section 4.1: Description of HTTPMU- / DF federation-based approach |
|
0.B |
25/07/02 |
TC Adhoc |
Restructuring |
|
0.C |
23/08/02 |
Michael Berger |
Added abstract and introduction Incorporated input from Celeste Campo from Univ. of Madrid in requirements in Section 1.2; Section 2, DEAPspace, PDP, SLP, and Salutation; |
TABLE OF CONTENTS
Abbreviations................................................................................................................... 4
References........................................................................................................................ 5
1 Introduction.............................................................................................................. 6
1.1 Overview.................................................................................................................................................................... 6
1.1.1 Technologies for Mobile Adhoc Computing.............................................................................................. 6
1.1.2 Relevance for FIPA......................................................................................................................................... 6
1.1.3 FIPA’s Approach for Mobile Adhoc Computing – Scope of TC Adhoc............................................... 7
1.2 Requirements........................................................................................................................................................... 7
1.3 Technical Considerations of TC ADHOC.......................................................................................................... 8
2 Existing Discovery Mechanisms / Technologies.................................. 9
2.1 DEAPSpace............................................................................................................................................................ 12
2.2 Service Location Protocol (SLP)........................................................................................................................ 12
2.3 Jini............................................................................................................................................................................. 9
2.3.1 Discovery protocols....................................................................................................................................... 9
2.3.2 Join protocol.................................................................................................................................................... 9
2.4 PDP.......................................................................................................................................................................... 10
2.4.1 Application scenario..................................................................................................................................... 10
2.4.2 Algorithm description................................................................................................................................... 10
2.5 Salutation............................................................................................................................................................... 12
2.6 UPnP........................................................................................................................................................................ 11
2.6.1 UPnP networking protocols......................................................................................................................... 11
3 Generic FIPA Architecture Proposals for Agents in Ad Hoc Environments 13
4 Concrete APProaches for FIPA Agents in AD-hoc environments15
4.1 Platform and Service Discovery Approach based on HTTPMU-Multicast and DF-Federation.............. 15
4.1.1 Preliminary reflections.................................................................................................................................. 15
4.1.2 Basic idea........................................................................................................................................................ 16
4.1.3 Ad hoc management service component.................................................................................................. 16
4.1.4 ImplementatioN.............................................................................................................................................. 19
4.2 Further solutions.................................................................................................................................................. 20
5 Additional Mechanisms...................................................................................... 21
6 CUrrently Known ImplementationS......................................................... 22
6.3 Siemens Implemenatation................................................................................................................................... 22
Abbreviations
ACC Agent Communication Channel
ACL Agent Communication Language
AID Agent Identifier
AMS Agent Management System
BT Bluetooth
DF Directory Facilitator
DHCP Dynamic Host Configuration Protocol
FIPA Foundation for Intelligent Physical Agents
GPRS General Packet Radio Service
GSM Global System for Mobile Communications
GUID Globally Unique Identifier
HAP Home Agent Platform
HTTPMU UDP Multicast of HTTP Messages
HTTPU UDP-based HTTP
IrDA Infrared Data Association
RMI Remote Method Invocation
SLP Service Location Protocol
SOAP Simple Object Access Protocol
SSDP Simple Service Discovery Protocol
UPnP Universal Plug & Play
WLAN Wireless Local Area Network
References
[DEAPspace] M. Nidd. Service Discovery in DEAPspace. IEEE Personal Communications, Aug. 2001.
[FIPA00001] Foundation for Intelligent Physical Agents. FIPA Abstract Architecture Specification, August 2001. Document Number XC00001J.
[FIPA00023] Foundation for Intelligent Physical Agents. FIPA Agent Management Specification, October 2001. Document Number XC00023H.
[FIPA00067] Foundation for Intelligent Physical Agents. FIPA Agent Message Transport Service Specification, August 2001. Document Number XC00067D.
[FIPA00084] Foundation for Intelligent Physical
Agents. FIPA Agent Message Transport
Protocol
for HTTP Specification, August 2001. Document Number XC00084D.
[HTTPMU] Y. Goland, J. Schlimmer. Multicast and Unicast UDP HTTP Messages, October 2000. UPnP Forum Technical Committee, Document draft-goland-http-udp-04.txt.
[JADE] http://jade.cselt.it. Homepage of Java Agent Development Framework (JADE).
[JINI] Sun Microsystems, Inc. Jini Architecture Specification, 2001.
[LEAP] http://leap.crm-paris.com. Homepage of European Community project LEAP.
[PDP] Celeste Campo. Directory Facilitator and Service Discovery Agent. Contribution to FIPA TC Adhoc, July 2002.
[SALUT] I. Salutation Consortium. Salutation architecture overview. Technical report, 1998.
[SLP] IETF Network Working Group. Service Location Protocol, 1997.
[UPNP] Microsoft Corporation. Understanding Universal Plug and Play, June 2000. Whitepaper.
1 Introduction
1.1 Overview
In the last years developments in wireless data communications (such as GSM, GPRS) and mobile devices (such as PDAs and mobile phones) were combined resulting in a trend: “mobile computing”. Users could significantly benefit from mobile computing in many situations and agent technology has been proven to be an enabler for intelligent applications in that domain. Examples include electronic commerce, information retrieval and mobile team support (e.g. see the European projects LEAP and CRUMPET). FIPA has recognized the importance of mobile computing and provides agent standard solutions like a bit-efficient ACL and envelope encoding for connections with low bandwidth.
In contrast to that, until now FIPA has no solutions for agents interoperating in “mobile adhoc computing” environments, a currently upcoming and even more exiting and promising agent application area. Examples can be found in office or meeting environments or when people are passing shops or other people in the street. Before describing FIPA’s activities to develop solutions for these environments, a short introduction to the technologies behind is given.
1.1.1 Technologies for Mobile Adhoc Computing
Mobile adhoc computing is possible because of new technologies for short range wireless data communication such as Wireless LAN and Bluetooth. Devices, equipped with the same type of that technology make the communication and collaboration between them possible, as soon as the devices coming in communication range. The resulting “mobile adhoc network” (MANET) is very flexible because it has a dynamic topology where nodes are free to move arbitrarily and it allows a Peer-To-Peer (P2P) communication in an asynchronous manner without any pre-installed networking infrastructure.
Beside that, the development goes in the direction of very small devices with even more limited system resources in terms of memory and processing power than PDAs or mobile phones have. Such devices will be mostly hidden in the environment as acting or sensing elements, e.g. embedded in household appliances or in intelligent air conditioning systems and allow to extend the mobile adhoc domain, also called as “pervasive computing”.
In mobile adhoc environments each of the devices may host agents offering specific services to the surrounding which can directly be used or may be combined to more complex services. Several different technologies were developed in order to describe as well as discover and share services. Some of them provide an API to infrastructure elements (e.g. Jini, Salutation), others provide no infrastructure but specific protocol implementations needed on every device (e.g. UPnP, Bluetooth SDP). Devices, equipped with that technology, allow the discovery, as soon as devices hosting services coming in communication range and will release the service after the device is out of communication range.
In parallel to these developments, also dynamic service discovery technologies, e.g. SLP, Gnutella, JXTA, were developed for fixed (Internet based) P2P-networks handling the dynamic availability of nodes. The variety reaches from approaches with central elements, over pure P2P solutions until advanced P2P systems which distribute / replicate the service directory entries in an intelligent way. Because of the same nature, technologies developed for fixed P2P-networks can in general also be used for MANETs.
A detailed introduction to existing dynamic discovery technologies will be given in Section 2.
1.1.2 Relevance for FIPA
Based on the traditional DF definition (FIPA’s Yellow Pages), the search of remote services is accomplished by using the concept of DF federations: DFs, besides registering services offered by local agents, may also register other DFs (local or remote ones). This allows them to extend the search for services to remote platforms. This mechanism is not efficient, even less for mobile adhoc environments, e.g. because the searcher first has to find the remote DF and afterwards to look if the service he is searching for is registered there. Allowing to register and discover agent services using existing adhoc / P2P discovery technologies which are specifically developed for these environments can enable a more efficient management of service descriptions and directories as well as an efficient search and result filtering. Furthermore, once working in mobile adhoc environments, adhoc and P2P technologies can also be used as mechanisms for agent (platform) societies in the fixed network.
1.1.3 FIPA’s Approach for Mobile Adhoc Computing – Scope of TC Adhoc
The development of dynamic service discovery technologies is still an ongoing research topic. It is not yet presumably, which technology will finally be widely adopted and be the leading one. All of them have specific advantages and disadvantages and do not completely fit all requirements. E.g., some are not dealing well with MANET’s spontaneity of the peer communication and fast changing service provisioning while others are not dealing well with the scalability for a huge amount of services and users.
Although, FIPA recognized the big potential of adhoc computing and decided to be one of the first adopters of current dynamic service discovering technologies. FIPA has created a Technical Committee “Adhoc” in February 2002 with the mission to develop solutions enabling agents to interoperate in mobile adhoc environments.
Currently the TC is writing that whitepaper in order to collect and structure all technical contributions received. Based on that whitepaper, the TC will come up with a first draft of a preliminary specification.
If you are interested in participating in that work, please contact the TC-Chair Michael Berger (m.berger@siemens.com) or the co-chair Heikki Helin (heikki.j.helin@sonera.com). Information can also be found on our website http://www.fipa.org/activities/ad_hoc.html.
1.2 Requirements
There are tree major requirements from a global point of view to the solutions to work out:
- Add minimal changes to FIPA specifications
- Use as much as possible existing mechanisms when appropriate
- Solution focus is for mobile local / personnel adhoc environments, but it should not prevent solutions for large scale environments (discovery of platforms in a large-scale deployment)
The future specifications should apply to the following considerations: (terms like mobility, scale, device constraints)
The dynamic topology of ad-hoc networks, the fluctuating quality and capacity of wireless links, and the limited capacity (memory, processing power, and battery life) of many of the devices connected to this kind of networks, pose important, new challenges that should be addressed when defining new proposals for this environment. In the following, some of the requirements of ad-hoc networks, different of those of fixed P2P or mobile computing networks, are presented:
· Distributed operation: In ad-hoc environments, nodes join and leave the network spontaneously, so network operation must be distributed between all the devices that form the network at any given time. This is one of the requirements that more differ from traditional networks. In traditional networks, some elements perform special tasks without which the global operation of the network is not possible. For example, in GSM, network operation rely on the existence of base stations. Terminal equipments connect to these base stations to obtain connectivity and to access services.
· High cost of the communications: Communications in ad-hoc networks are expensive because they imply high battery consume in devices typically with limited battery power.
· Intransitive connectivity: In fixed networks, if A has connectivity with B, and B has connectivity with C, then A has connectivity with C. In ad-hoc networks this may not be true due to the short-range coverage of the underlying wireless protocols.
· Very changing environments: Nodes in ad-hoc networks continually change (join and leave the network).
· Broadcast domains: In ad-hoc networks, you can use broadcasts to reach all nodes in your range, that is, all the nodes you are able to communicate with. In fixed networks, broadcast domains are constrained to closer nodes (those within your local area network), and so broadcasts do not reach all nodes you are able to communicate with.
In other words, mobile adhoc environments need solutions considering the following constraints:
- the focus of the TC are small devices with less power -> only minmal message exchange
- envrionments with a few participats only (large scale is not the focus)
- the flexibility of handling in-and outgoing devices and services is a high requirement
- no central server can be used
1.3 Technical Considerations of TC ADHOC
There are tree levels of interest in the current discussions of the TC:
- Which extensions / changes to the FIPA architecture are needed?
- How FIPA agent services have to be represented for various service discovery technologies? Which discovery technologies should FIPA use / adopt?
- Which other related mechanisms FIPA has to consider in order to work in these environments (e.g. policy definitions for service announcements, security problems)?
2 Existing Discovery Mechanisms / Technologies
2.4 Jini
The purpose of a Jini system, developed by Sun Microsystems, is to federate users, devices and services into a distributed system providing on the one hand a single, integrated view on it and, on the other hand, a highly dynamic infrastructure for devices and services to join and detach from the network [JINI].
The notion of a service is the central concept of Jini. A service (represented as Java object) is a software entity providing any kind of computation or controlling a hardware device, e.g. a file converter or a printer service. Services can make use of each other, and one service can be client of another one. Communication between services is based on Java Remote Method Invocation (RMI).[1]
Services are made available to potential clients in the network by putting a corresponding service entry into a directory or lookup service (similar to the Directory Agent in SLP), named the Jini Lookup Service (JLS), which maps interfaces indicating the service's functionality to an object which implements the service. For addition of a service to a lookup service, two steps have to be performed: a discovery step to find out available lookup services a service can register with, and a join step to perform the registration.
2.4.1 Discovery protocols
There are three different types of discovery protocols: the multicast request protocol, the multicast announcement protocol and unicast discovery.
The unicast discovery protocol is used, when a service wants to register with an already known lookup service. The service addresses the lookup service using reliable unicast and receives a reference to the lookup service.
The multicast request protocol is used when a service is looking for a lookup service with which to register. Using unreliable multicast, the service periodically sends a request for lookup services, which contains a port number for unicast discovery. A relevant lookup service replies a reference to the lookup service using unicast discovery, thereby extracting the host name for the unicast discovery from the source address of the request.
The multicast announcement protocol is used, when a Jini lookup service wants to announce its availability. Using unreliable multicast, the lookup service periodically sends an announcement, which contains host name and port number for unicast discovery. A service interested in a lookup service announcement then uses unicast discovery to receive a reference for the lookup service.
2.4.2 Join protocol
When a lookup service has been determined with which the service wants to register and the service has received a reference to the lookup service, the join protocol is applied: a service proxy object and additional descriptive attribute objects are registered with the chosen lookup service. The service proxy object contains the Java programming language interface of the service and allows to communicate with the actual service object, or even contains the code for the service implementation by itself (a so called smart proxy), or both.
Lease mechanism
When a service registers with a lookup service, it receives a lease. Periodically, the service needs to renew this lease with the lookup service to indicate to the lookup service, that it is still alive. If the lease is not renewed, it expires, and the lookup service removes the corresponding service entry. Thus, the service is no longer available.
Lookup
When a client looks for a certain service with a given Java programming language interface type and a set of additionally requested, descriptive service attributes, it addresses a lookup service and demands all services that match it, i.e. implement the given interface and match all the requested attributes in type and value. The lookup service responses with a set of proxy objects for the matching services. The client in turn selects a certain proxy object to invoke one of the service's methods.
In situations, where no lookup service can be found, a client could use a lookup technique called peer lookup. The client sends out the same identification request as a lookup service would send out to request service providers to register (multicast announcement). Then, the service providers attempt to register with the client as if it was a lookup service, but the client itself filters incoming service offerings best suitable to its needs.
2.5 PDP
The Pervasive Discovery Protocol (PDP) [PDP] is intended to solve the problem of enumerating the services available in a local cell in a low power short-range wireless network, composed of devices with limited transmission power, memory, processing power, etc. The classical service discovery protocols use a centralised server that listens for broadcast or multicast announcements of available services at a known port address, and lists the relevant services in response to enquiries. The protocol we propose does away with the need for the central server. The kind of environments described above cannot be relied upon to have any single device permanently present in order to act us central server, and further, none of the devices present at any moment may be suitable to act as the server.
One of the key objectives of the PDP is to minimise battery use in all devices. This means that the number of transmissions necessary to discover services should be reduced as much as possible. A device announces its services only when other devices request the service. Service announcements are broadcast to all the devices in the network, all of which will get to know about the new service simultaneously at that moment, without having to actively query for it.
2.5.1 Application scenario
We will suppose that there are D devices, each one with I network interfaces. Each device offers S services and expects to remain available for T seconds. This time T is previously configured in the device, depending on its mobility characteristics. The Distributed DF fragment has a cache associated with each interface which contains a list of the services that have been heard from on this interface. Each element e of this list has two fields: the service description, e.description, and a time that it is calculated that the service will be available for, e.timeout. The calculation is exactly the minimum of two values: the time that the local device has promised to remain available, T , and the time that the server that offers the service announced that it would be available for.
Services are not associated with any specific interface and the availability time T of the device is always included in the announcements of its services. For simplicity, we suppose that local services are stored in the cache associated with the loopback interface ( cache0 ).
2.5.2 Algorithm description
The PDP has two messages: PDP request, which is used to send service announcements and PDP reply, which is used to answer a PDP request, announcing available services.
Now, we will explain in detail how a Distributed DF fragment uses these primitives.
PDP request
When an application or the final user of the device needs a service, whether a specific service or any service offered by the environment, it requests the service from the Distributed DF fragment. The number of broadcast transmissions should be minimised, so:
· If a specific service S has been requested, the Distributed DF fragment searches for that service in all its caches. If it is not found, it broadcasts a PDP request for that service).
· If the request is for all available services in the network, the Distributed DF fragment updates its caches by sending a PDP request message through all the interfaces of the device.
PDP reply
The Distributed DF fragments in all devices are continually listening on each interface for all type of messages (PDP requests and PDP replies).
When a PDP reply is received, announcing a service, the Distributed DF fragments update their caches accordingly.
When a PDP request for a specific service S is received then the Distributed DF fragment:
· Checks whether the requested service S, is one of its local services and therefore is stored in the loopback cache, or is not.
· If not, it generates a random time t , inversely proportional to the availability time of the device, T . So, the more time the device is able to offer the service, the higher the probability of the device answering first.
· During the interval t , the Distributed DF fragment listens to the network. If another reply to this PDP request arrives, it aborts its PDP reply, otherwise when the interval expires, it sends its PDP reply.
When a PDP request for all services ALL is received then the Distributed DF fragment:
· Generates a random time t , inversely proportional to the availability time of the device, T , and to the number of elements stored in the cache of that interface. So, the more time the device is able to offer the service and the biggest the cache, the higher the probability of answering first. We suppose the device with the highest availability time and the bigger cache is the one with the most accurate view of the world.
· During the interval t , the Distributed DF fragment listens to the network. If another reply to this PDP request arrives, it aborts its PDP reply, otherwise when the interval expires, it sends its PDP reply listing the services in the loopback cache plus the services in the cache of that interface.
2.6 UPnP
A UPnP network consists of three basic building blocks: devices, services and control points [UPNP]. A device is a container for services and nested devices. A service is basically the smallest unit of control, which offers a set of actions. Internally, a service consists of a state table maintaining the service state, a control server and an event server. The control server receives requests for actions, executes them, updates the service state and returns corresponding responses. The event server announces events on state changes to interested subscribers. A control point in a UPnP network provides capability of discovering and controlling devices by receiving device and service descriptions, invoke service actions, or subscribe to a service's event source in order to be notified each time the service changes its state.
For both a device as well as a service, all information characterizing it is captured in XML-based device or service description, which is made available under a certain URL.
2.6.1 UPnP networking protocols
In contrast to Jini, which provides an infrastructure and an API, UPnP is based upon the specification of protocols for communication between control points, devices and services. The different tasks necessary in a Plug & Play environment such like discovery of services or service invocation are solved in UPnP by certain protocols, thus allowing UPnP to be media and platform independent. For different tasks in UPnP networking, there is provided a corresponding protocol based upon open internet standards such as TCP/UDP/IP, HTTP and XML.
For IP addressing in a UPnP network, each device must have a Dynamic Host Configuration Protocol (DHCP) client which looks for a DHCP server once a device is first connected to the network. If a DHCP server is available, the device takes the designated IP address, otherwise, the device uses AutoIP to obtain an IP address.
Concerning discovery, Simple Service Discovery Protocol (SSDP) was created as a lightweight discovery protocol for Universal Plug-and-Play (UPnP) initiative, and defines a minimal protocol for multicast-based discovery. The SSDP is built upon HTTPU[2] and HTTPMU[3] and allows for a control point to look for devices and services, and for a device to announce its availability. A UPnP control point sends out an SSDP search request over HTTPMU to discover devices and services available on the network. A UPnP device in turn listens to the multicast port. When a search request is received, the device checks whether the search criteria match its device and service description. If there is a match, the device sends a HTTPU response back to the control point. Due to such an approach, UPnP does not need any lookup service. Similarly, a device may multicast multiple SSDP presence announcements advertising its provided services.
SSDP can also work with a central directory service, called the Service Directory. When a service wants to join the network, first it sends an announcement message by HTTPMU to notify its presence to the rest of the devices. This announcement may be sent by multicast, so all other devices will see it, and the Service Directory, if present, will record the announcement. Alternatively, the announcement may be sent by unicast directly to the Service Directory. When a client wants to discover a service, it may ask the Service Directory for it or it may send a multicast message asking for it.
Once an appropriate service has been identified, Simple Object Access Protocol (SOAP) is used for an invocation of a service action.
· BT-SDP (Michael)
· JXTA (Heikki)
· Others (Michael)
Gnutella
Chord
2.1 DEAPSpace
In mobile adhoc computing, it is very important to minimise the total number of transmissions, in order to reduce battery consume. It is also important to implement mechanisms to detect as soon as possible both the availability and unavailability of services produced when a device joins or leaves the network. These factors must be taken into account when selecting between a push solution or a pull solution.
The DEAPspace group of the IBM Research Zurich Lab has proposed a solution to the problem of service discovering in mobile adhoc systems without using a central server. The DEAPspace Algorithm [DEAPspace] is a pure push solution, in which all devices hold a list of all known services, the so called “world view”. Each device periodically broadcasts its “world view” to its neighbours, which update their “world view” accordingly. Nevertheless, the DEAPspace algorithm has the following problem: the “world view” of a device spreads from neighbour to neighbour, perhaps arriving to a device where some of those services are in fact not available.
2.2 Service Location Protocol (SLP)
The Service Location Protocol (SLP) [SLP] is an Internet Engineering Task Force standard for enabling IP networks-based applications to automatically discover the location of a required service. The SLP defines three “agents”: User Agents (UA), that perform service discovery on behalf of client software, Service Agents (SA), that advertise the location and attributes on behalf of services, and Directory Agents (DA), that store information about the services announced in the network. SLP has two different modes of operation: when a DA is present, it collects all service information advertised by SAs, and UAs unicast their requests to the DA, and when there is not a DA, UAs repeatedly multicast the request they would have unicast to a DA. SAs listen for these multicast requests and unicast responses to the UA.
2.3 Salutation
Salutation [SALUT] is an architecture for looking up, discovering, and accessing services and information. Its goal is to solve the problems of service discovery and utilisation among a broad set of applications and equipment in an environment of widespread connectivity and mobility. The Salutation architecture defines an entity called the Salutation Manager (SLM) that functions as a directory of applications, services and devices, generically called Networked Entities. The SLM allows networked entities to discover and to use the capabilities of the other networked entities.
3 Generic FIPA Architecture Proposals for Agents in Ad Hoc Environments
· Device Discovery: not in the focus of FIPA, possible technologies are BT, WLAN, IrDA
· Platform discovery
· Platform discovery over adhoc and than using FIPA or other existing mechanisms for service discovery
· Service Discovery
Discussion of service discovery protocols
· Discussion of infrastructure elements needed for ad hoc support
· Discussion of message exchange on agent level
· Only current FIPA mechanisms?
· Additional features
· Discussion of mechanisms to support policies and security in ad hoc environments
 |
· Possible Infrastructure
AMSlite, ontology, ACC ?...
Discovery Service (e.g. DF), or Agent or just a protocol for the DF?
Definition of agent platform fragments
Implications to X2S
The 5 main architectural approaches, pros and cons
1.) platform discovery and DF federation (not efficient in mobile adhoc), more for stable environments
2.) Multiple DFs for different technologies
3.) DF plug-ins for discovery protocols
4.) Service Discovery Channel (SDC)
5.) Discovery Agent in parallel to DF (Jamie, Celeste)
Final Decision? 4 or 5?
Questions:
Announce local services and federate DF‘s at the same time? Is that possible?
Change the DF interface in a way that an agent can say if he wants to be registered only locally or remotely? Is that implementation dependent?
What are the main P2P technologies? Can we focus on them? (Bluetooth, JXTA, Gnutella, HTTPMU, ) The interfaces are specified like in a library.
Possible considerations:
Platform announcement (e.g. by BT-SDP, HTTPMU, JXTA, UPnP, JINI, ...) and then DF federation or service announcements
Only Service announcements or (DF announcements and DF federation)
4 Concrete APProaches for FIPA Agents in AD-hoc environments
4.1 Platform and Service Discovery Approach based on HTTPMU-Multicast and DF-Federation
4.1.1 Preliminary reflections
The agent infrastructure for an ad hoc communication hosted on a mobile device is characterized by the need for autonomy. It must be able to act completely autonomously, without the need for communication with any other parts of infrastructure, that it cannot live without. Firstly, it cannot be guaranteed that such additional parts are also available in an ad hoc communication range. Secondly, if such additional parts of the agent infrastructure were in an ad hoc communication range, it cannot be guaranteed, that the connection in between is reliable from the physical point of view. The idea of an ad hoc communication is to provide a spontaneously, not permanently available communication connection instead of a durable and reliable connection.
The notion of the abstract architecture of a FIPA-compliant agent platform [FIPA00001] is self-contained and logically provides the required autonomy. Although FIPA does not specify any requirements how a concrete architecture of an agent platform obeying the guidelines of the FIPA abstract architecture has to look like, being able to communicate in an ad hoc manner has some implications on it. For example, if the concrete architecture of an agent platform as an instance implementing the FIPA abstract architecture is distributed over a set of several hosts, some of which physically support ad hoc communication, there may occur the problem, that existential communication between certain platform hosts is not possible to be based upon ad hoc communication, e.g. because the distance between them is too large or an platform host taken as communication endpoint does not support it. Requiring an additional, non-ad hoc, communication channel to other parts of the distributed platform in order to enable ad hoc communication is not reasonable.
An example of a distributed FIPA-compliant agent platform is JADE-LEAP[4] [JADE] [LEAP], a scalable agent platform which allows to run agents hosted on PCs as well as on small mobile devices such as PDAs or mobile phones. The JADE-LEAP agent platform spans several hosts distributed over the network. On each host, there is running an agent container, which provides agent communication within the platform and, if the host is powerful enough, agent communication between different agent platforms. One of these containers has to be a main container, that is emphasized against the other containers. The main container hosts the agent management system (AMS) and a default directory facilitator (DF). According to the FIPA standard, the AMS represents the management authority of an agent platform. It is responsible for agent creation and deletion, maintenance of a white-page directory service every agent residing on the agent platform has to be registered with, and agent life-cycle management. If the agent platform spans several hosts, the AMS represents the authority across all hosts. So, a container hosted on a mobile device that wants to communicate in an ad hoc manner with an agent living in another agent platform, may need a non-ad hoc connection (e.g. based on TCP/IP over WLAN, GSM or GPRS) to the main container of the platform.
Thoughts concerning the introduction of agent platform fragments
To achieve the required autonomy of such a container, or more abstractly, a distributed platform fragment, there has to be provided a mechanism for a platform fragment to autonomously set up a federation with another platform fragment of another agent platform. Such an approach has to comprise a solution for directory facilitator (DF) management. Assume, one platform fragment has a local DF and the other one has not. In order to make the agents living in the fragment without any DF available, they have to register with the other DF. Or assume, that both platform fragments don't have any DF. There has to be decided which fragment sets up a DF, and agents in both fragments register with it. Note, that such an approach may lead to scalability problems in case there are several platform fragments that want to set up a shared DF, because all fragments have to decide with which DF to register and then register all their agents.
The problem is much easier to solve, if each mobile device has a complete agent platform running, including agent management system (AMS) and directory facilitator (DF). There a three advantages. Firstly, in terms of the FIPA standard, it is much easier to provide some specification for ad hoc agent communication, because the notion of the platform fragment and its management (with all implications this may lead to) does not have to be introduced. Because of the mandatory AMS and DF according to the FIPA abstract architecture, one can ensure that each mobile device has its own AMS and DF reflecting the agents living on it. Secondly, as already mentioned above, the notion of the FIPA abstract architecture of an agent platform is self-contained, thus being able to provide the required autonomy. Thirdly, resource restrictions of mobile devices are expected to become less important than today. Thus, the basic idea for this approach is to host a complete FIPA-compliant agent platform on the mobile device.
4.1.2 Basic idea
The following outlined approach assumes that a mobile device hosts a complete agent platform obeying the guidelines of the FIPA abstract architecture [FIPA00001]. The whole proposition is oriented on existing FIPA specifications in order to achieve a FIPA ad hoc management capability without possibly having to reorganize a large number of existing FIPA specifications.
The basic idea is that each agent platform periodically broadcasts an agent platform announcement message of itself. If at least two mobile devices are in range for ad hoc communication, both agent platforms receive the agent platform announcement messages and become aware of each other.
Having discovered each other, the agent platforms form a kind of logical interconnection, an ad hoc agent platform federation. During an ad hoc agent platform federation, the agent platforms remain physically distinct. It is not necessary to federate the agent management systems (AMS) of each platform, but to mutually make agents of each platform accessible by the services they provide, the directory facilitators (DF) of each platform have to be federated. Such a DF federation has two important advantages:
§ FIPA already specifies a DF federation [FIPA00023], comprising search operations to cascade to a federated DF.
§ A DF federation does not require any remote replication of local DF records and therefore does not introduce any problems related to consistency and replication overhead.
§ Local applications operating in an ad hoc communication environment need not monitor the existence of remote agent platforms themselves. Applications running on the local agent platform automatically become aware of remote agent platforms due to the registration of their (remote) DFs with the local DF. Therefore, a local agent only has to query the local DF and yet transparently obtains all available agent services in ad hoc communication range.
It is important to note that an agent platform is not enforced to broadcast its agent platform announcement message. If an agent platform does not want agents living in remote agent platforms to use services registered with the local DF, it does not broadcast its agent platform announcement message. But note, unilaterally, it is yet possible for local agents to use services of remote agent platforms that have announced themselves. So there is a simple semantics of the broadcast of the agent platform announcement message: if an agent platform allows agents living in remote agent platforms to use services provided by local agents, it broadcasts its agent platform announcement message; if it does not want to, it does not.
Due to nomadism of mobile devices, an ad hoc connection may break down, which makes a lease mechanism reasonable to check whether a remote agent platform is still in ad hoc communication range or not. For each once discovered remote agent platform, a lease is maintained. Each time, the periodically broadcast agent platform announcement message of a remote agent platform is received, the corresponding lease is renewed indicating that the remote agent platform is still in ad hoc communication range. If the lease expires, the remote agent platform is no longer in ad hoc communication range and thus, the DF federation of the local and the remote agent platform is dissolved.
The functionality for setup, maintenance and dissolution of an ad hoc agent platform federation is bundled in an optional service component for ad hoc management. Section 4.1.3 gives a detailed view on this component.
4.1.3 Ad hoc management service component
The ad hoc management service component is an agent platform service component like AMS and DF. Its task is to manage setup, maintenance and dissolution of an ad hoc agent platform federation. It is proposed to adopt the ad hoc management service component as an optional agent platform component to the FIPA abstract architecture specification. Similar to AMS and DF, it is not directly to be specified by FIPA whether to implement the ad hoc management component as an agent platform component or as an agent.
Discovery of an agent platform
In order to discover other agent platforms in an ad hoc communication range, the ad hoc management service component both broadcasts an agent platform announcement message[5] over the medium of the underlying ad hoc communication technology, as well as listens for incoming announcement messages from remote agent platforms. Minimally, the agent platform announcement message has to comprise the home agent platform name (HAP name) and the transport profile of the agent platform containing message transport protocols (including transport addresses) an agent platform supports for inter-platform communication. By listening for incoming agent platform announcement messages, the ad hoc management service component learns about remote agent platforms.
From the point of view of the FIPA abstract architecture, there are two possible approaches to broadcast the agent platform announcement message. The first approach is to broadcast it on FIPA agent communication language (FIPA ACL) message level[6]. The second, alternative approach is to broadcast the information on the lower level of the agent platform's message transport system, which means to have a certain broadcast-enabled protocol and a standardized message scheme other than ACL. Which alternative is better to choose depends on the implementation of the ad hoc management service component. If the ad hoc service is implemented as an agent, the ACL message-based approach of course suits best.
Using ACL to broadcast the agent platform announcement message has several advantages in terms of FIPA:
§ The broadcast of the agent platform announcement message is a kind of inter-platform communication. For homogeneity with other inter-platform communication already specified by FIPA, there should be used the same mechanism for message exchange, i.e. using a certain transport protocol containing envelope plus ACL message as payload.
§ With ACL, there is no need to specify a representation scheme for the message content, because ACL clearly defines one (envelope and actual ACL message representation).
§ The transport protocol for delivering ACL messages between FIPA-compliant agent platforms such as IIOP or HTTP is on OSI network layers 5 and above. Using such a transport protocol allows to become independent from the underlying ad hoc communication technology and its supported transport protocols, which is especially important for future developments of ad hoc technology. For example, current ad hoc communication protocols do not support any multi-hop routing, or structural self organization including a solution for dynamic addressing is still topic of research.
As shown above, it is reasonable to use ACL to broadcast the agent platform announcement message. Because ACL messages are exchanged between agents, this implies to realize the ad hoc management service component in turn as an agent, even though FIPA does not rule how to implement it. In the framework of the solution proposed here, it is decided to implement the ad hoc management service component as an agent and use an ACL message for the broadcast of the agent platform announcement message.
Transport protocol for broadcast/multicast
For broadcast/multicast of agent platform announcement messages on ACL message level, it is necessary to specify a broadcast/multicast-capable message transport protocol, i.e. a protocol that both can send out and receive agent platform announcement messages to/from a given broadcast/multicast channel. A common broadcast/multicast channel must be agreed by all hosts before any communication is possible at all. Then, every host, that wants to become aware of remote agent platforms announces its agent platform announcement message and listens for incoming agent platform announcement messages from remote agent platforms on this pre-defined broadcast/multicast channel. The sender does not expect any acknowledgement, because it cannot know which, respectively how much, agent platforms do receive its own agent platform announcement message.
It is proposed here to use HTTPMU (UDP multicast of HTTP messages) as specified by UPnP Forum Technical Committee [UPNP]. HTTPMU uses the same message format as defined by HTTP/1.1 [HTTPMU]. The FIPA standard already defines a message transport protocol for the HTTP specification [FIPA00084]. A message transport protocol for the HTTPMU specification could be completely analogous to the FIPA HTTP specification as for the encoding of envelope and ACL message. It may be useful to restrict such an HTTPMU message transport protocol specification to the special purpose of agent platform announcement, i.e. that it need not be a request-response protocol like the FIPA HTTP message transport protocol. In this context note, in contrast to HTTP, HTTPMU does not require a receiver to respond with an acknowledgement [HTTPMU].
Compared with broadcast, multicast seems to be more flexible, because there is a large number of IP multicast addresses (Class D IP addresses, multicast channels) available which could avoid interference between several ad hoc communication groups, each of which would have agreed to send out and listen for agent platform announcement messages on a specific channel. Even more important, multicast provides a time-to-live counter and is not restricted to a certain sub-net. At the moment, both aspects are not important, but they might become important in future.
A problem with UDP is, that basically the complete agent platform announcement message has to fit into a single datagram. To avoid this problem, one could split an agent platform announcement message to several datagrams. Each datagram belonging to the same agent platform announcement message was labeled with the same identifier, the total number of datagrams of this announcement message, as well as a sequence number in order to reconstruct the agent platform announcement message correctly on reception.
Structure of an ACL-based agent platform announcement message
Basically, the agent platform announcement message is an ACL message with a REQUEST performative. The content language used is FIPA-SL0.
One important aspect of the agent platform announcement message is, that an AID of a receiver agent has to be specified in the :receiver slot, which is a priori not known. For this reason, a particular surrogate AID (“any-AID”) is introduced, which matches the ad hoc management service agent in each remote agent platform in ad hoc communication range. The surrogate AID uses a string constant, e.g. any as globally unique agent name (GUID). Its transport address is the common HTTPMU multicast channel a remote agent platform is listening for incoming agent platform announcement messages. FIPA so far does not support such a special kind of AID, which would thus require to introduce it.
As mentioned already, the ACL message must basically comprise the home agent platform name (HAP name) [7] and the transport profile of the agent platform containing transport addresses and protocols an agent platform supports for inter-platform communication. According to FIPA standard, both the HAP name as well as the agent platform transport profile are part of the agent platform description frame ap-description of the FIPA-Agent-Management ontology.
To be compliant with FIPA-SL0, the agent platform description has to be embedded into a well-formed FIPA-SL0 expression. It is proposed here to use an SL0 action frame with the surrogate AID as actor. As for the action slot, it is proposed to define a new AgentPlatformAnnouncement ontology only containing a single frame notice-ap-description. This frame defines the action to be executed by the receiving ad hoc management service agent, and it needs only a single ap-description frame slot containing the local agent platform description to be broadcast/multicast. The semantics of the notice-ap-description action is self-explanatory: the receiver is to notice the received agent platform description and so gets aware of the corresponding agent platform.
ACC modifications to handle the surrogate AID
It is important to note, that the ACC of an agent platform must be able to dispatch a received agent platform announcement message to the really existing, local ad hoc management service agent. Thus, the ACC has to map the surrogate AID (matching any ad hoc management service agent) to the local ad hoc management service agent’s AID. The current FIPA ACC specification has to be extended how to deal with such surrogate AIDs.
Setup of DF Federation
The ad hoc management service agent sends out the agent platform announcement message periodically. Simultaneously, it listens for incoming announcement messages. When the ad hoc management service agent receives an announcement message from another (remote) agent platform, it extracts the agent platform description. If the ad hoc management service agent is not yet aware of the remote agent platform, two steps are performed.
In the first step, the transport profile of the remote agent platform is compared with the transport profile of the local agent platform. If there is a common reliable message transport protocol[8] (i.e., a reliable message transport protocol that both agent platforms support), it is used for communication to set up a DF federation. If there is no such common reliable message transport protocol, a reliable communication between the agent platforms is not possible and no DF federation can be set up.
In this context, it is important to note, that the unreliable HTTPMU message transport protocol should only be used for agent platform announcements, that means to apply it, where broadcast/multicast is essential and reliability cannot be reached anyway. For other inter-agent platform communication, always a reliable message transport protocol should be used.
Another problem with HTTPMU is the limited datagram size. As shown above, messages cannot be guaranteed to fit in a single datagram and a mechanism is needed to deal with this case. In order to minimize the overhead from such a mechanism, always stream-based transport protocols should be used unless it is absolutely inevitable.
In the second step, if there is a common reliable message transport protocol, the local DF is federated with the remote DF. The current FIPA standard specifies a DF federation: a DF is allowed to register with another DF. The registered DF agent description has to be associated with a service description indicating service type fipa-df. As for DF search, such a federation extends a single DF search to also search the federated DF for suitable agent services. With the max-depth slot in DF search-constraints, the FIPA standard also already defines a possibility to limit the DF search depth in case a federated DF in turn contains references to other DFs [FIPA00023].
In order to set up a DF federation, the ad hoc management service agent registers the remote DF with the local DF. The HAP name of the remote agent platform description can be evaluated from the agent platform description received with the agent platform announcement message. Assuming that the GUID naming scheme conforms to <agentname>@<hap-name>, the GUID of the remote DF is df@<hap-name>. The transport profile, too, is part of the remote agent platform description. That way, the transport addresses for the DF agent description of the remote DF can directly be taken from the transport profile that comes with the remote agent platform description. The HTTPMU transport address is not an element of the set of transport addresses of the DF agent description of the remote DF.
Lease Management and Dissolution of DF federation
In order to decide whether a remote agent platform is no longer in ad hoc communication range or not, for each remote agent platform that has been identified, the ad hoc management service agent maintains a lease table.
If a new remote agent platform has been detected, a lease with an initial age is created for it and put to the lease table.
The lease table is updated cyclically. For every lease is checked, whether it has expired. If a lease has not yet expired, its age is increased. The age of a certain lease is reset to its initial value whenever an agent platform announcement message from the corresponding remote agent platform has been received again.
If a lease has expired, it is removed and the remote DF is deregistered from the local DF.
It is important to note, that until lease expiration, there can occur inconsistencies between the DF federation and the ability to communicate in an ad hoc communication range, i.e. agents living in a remote agent platform may not be able to communicate with in spite of their remote DF is still registered with the local DF. Similarly, this condition may hold during DF search. Thus, implementations of DF search as well as communication between application agents have to take into account, that a remote agent may not be reachable anymore.
In order to avoid such inconsistencies as far as possible, an additional mechanism could be added, that deregisters a remote DF, if one its registered agents is detected to be no longer in ad hoc communication range, but this would require to locally maintain information whether an agent is registered with the local DF or the remote DF.
4.1.4 ImplementatioN
Siemens has implemented a first demonstrator as a proof-of-concept which follows this proposal. It is based on JADE-LEAP [JADE] [LEAP], a scalable distributed agent platform which allows to run agents hosted on PCs as well as on small mobile devices such as PDAs or mobile phones.
As for the hardware, the demonstrator runs on mobile devices that support ad hoc communication based on WLAN (IEEE802.11) and provide a Personal-Java platform, such as the Siemens SX45 or Compaq ipaq.
Along with given the proposal, each mobile device has a complete JADE-LEAP agent platform running on it. As for the agent platform itself, only minor modifications of the ACC have been done in order to handle surrogate AIDs. The ad hoc management service component has been realized as an agent.
Additionally, an implementation of HTTPMU is provided; but note, this implementation is not guaranteed to be fully compliant with the HTTPMU standard [HTTPMU]. One class D IP address is used as pre-defined multicast channel, on which all mobile devices are broadcasting its own agent platform announcement message and are listening for incoming ones. For reliable inter-platform communication, HTTP is applied with non-routable (private network) IP addresses.
As for an application, there has been implemented a simple one showing that a DF of a remote agent platform is available and has been federated with the local DF.
4.1.5 Summary of important POINTS for FIPA
Platform Announcement and DF Federation
Wiederverwendung des Managers
Announcement Message in HTML, Example
4.2 Further solutions
e.g. how to define an ACC / platform description (<URL>, <serviceID>, <JiniServiceID>)
The solutions are according to the mechanisms and may be completely different (e.g. for Bluetooth and JXTA)
· BT
· Jini
· UPnP
· JXTA
· others
Gnutella , SCP / SSDP / Chord, Salutation
5 Additional Mechanisms
· Caching
· Profiling / PolicY
· Security (WG Security)
6 CUrrently Known ImplementationS
6.3 Siemens Implemenatation
Definition of ACL broadcast / multicast (+ implications to X2S)
pull; push, subscribe (just one predicate?)