Agents in Ad Hoc Environments

 

 

A Whitepaper

 

 

Version: 0.A

 

Abstract: tbd.

 

Editor: Michael Berger

 

Document History:

Version

Date

Author

Change

0.A

04/07/02

Michael Berger (Siemens)

Template

 

22/07/02

Michael Watzke, Michael Berger (Siemens)

Section 2.4: Overview of Jini

Section 2.5: Overview of UPnP

Section 4.1:Description of HTTPMU- / DF federation-based approach

0.B

25/07/02

TC Adhoc

Restructuring

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

TABLE OF CONTENTS

Abbreviations................................................................................................................... 3

References........................................................................................................................ 4

1     Introduction.............................................................................................................. 5

1.1            Scope of TC AD-hoc................................................................................................................................................ 5

1.2            Technical Considerations...................................................................................................................................... 5

2     Existing Discovery Mechanisms / Technologies.................................. 6

2.3            Jini............................................................................................................................................................................. 6

2.3.1          Discovery protocols............................................................................................................................................ 6

2.3.2          Join protocol......................................................................................................................................................... 6

2.4            UPnP.......................................................................................................................................................................... 7

2.4.1          UPnP networking protocols............................................................................................................................... 7

3     Generic FIPA Architecture Proposals for Agents in Ad Hoc Environments       9

4     Concrete APProaches for FIPA Agents in AD-hoc environments10

4.1            Platform and Service Discovery Approach based on HTTPMU-Multicast and  DF-Federation.............. 10

4.1.1          Preliminary reflections....................................................................................................................................... 10

4.1.2          Basic idea............................................................................................................................................................ 11

4.1.3          Ad hoc management service component....................................................................................................... 11

4.1.4          ImplementatioN.................................................................................................................................................. 14

4.2            Further solutions.................................................................................................................................................. 15

5     CUrrently Known ImplementationS......................................................... 16

5.3            Siemens Implemenatation................................................................................................................................... 16

6     Additional Mechanisms...................................................................................... 17

 

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

SOAP                     Simple Object Access Protocol

SSDP                      Simple Service Discovery Protocol

UPnP                      Universal Plug & Play

WLAN                   Wireless Local Area Network

 

 

 

References

[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.

[UPNP]                  Microsoft Corporation. Understanding Universal Plug  and Play, June 2000. Whitepaper.

1         Introduction

Siemens

1.1          Scope of TC AD-hoc

 

Scenarios

I'd like to see a firm view from FIPA on the types of user scenarios and their attributes (as I said, in terms of the mobility, scale, transience of the network and the device constraints) to which any future specification will apply.  Is it discovery of platforms in a large-scale deployment like Agentcities?  small scale personal ad-hoc networks?  An office or meeting environment?  passing people in the street?

1.2          Technical Considerations

·         Device Discovery: not in the focus of FIPA,  possible technologies are BT, WLAN, IrDA

·         Platform discovery mechanisms

·         Discussion of relevant platform discovery protocols and FIPA specific adaptations

·         Service Discovery mechanisms

Discussion of service discovery protocols

·         Discussion of infrastructure elements needed for ad hoc support

·         Discussion of message exchange on agent level

·         Additional features

·        Discussion of mechanisms to support policies and security in ad hoc environments

 

 

 

 

 

 

 

 


1.3          Requirements

Make the solution as easy as possible

Use as much as possible the underlaying P2P functions

Differentiate between local ad-hoc and wide area P2P ?

 

 

2         Existing Discovery Mechanisms / Technologies

2.4          Jini

The purpose of a Jini system 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 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 lookup service 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          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.5.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, the Simple Service Discovery Protocol (SSDP) built upon HTTPU[2] and HTTPMU[3] allows both 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 provide any lookup service. Similarly, a device may multicast multiple SSDP presence announcements advertising its provided services. 

Once an appropriate service has been identified, Simple Object Access Protocol (SOAP) is used for an invocation of a service action.

·         UDP (HTTPMU, own) Fujitsu, Siemens

·         BT UMBC

·         JXTA Media Lab Europe, Siemens

·         Salutation Sonera

·         Routing / MANET Media Lab Europe

·         SCP / SSDP / Chord Siemens

·         Gnutella Uni Saskatchewan

·        others all

 

3         Generic FIPA Architecture Proposals for Agents in Ad Hoc Environments

·        Possible Infrastructure Siemens

DA, policy manager, AMSlite, ontology, ACC ?...

Discovery Service (e.g. DF), or Agent or just a protocol, leasing

Definition of agent platform fragments

Implications to X2S

 

The 5 main architectural approaches, pros and cons

Final Decision

 

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.

 

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.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)

·         UDP (HTTPMU, own) Fujitsu

·         BT UMBC

·         Jini Media Lab Europe

·         UPnP Fujitsu

·         JXTA Media Lab Europe, Siemens

·         Salutation Sonera

·         Routing / MANET Media Lab Europe

·         SCP / SSDP / Chord Siemens

·         Gnutella Uni Saskatchewan

·         others all

5         Additional Mechanisms

UMBC, Queen Mary London

·         Caching

·         Profiling / PolicY

·        Security (WG Security)

6         CUrrently Known ImplementationS

Siemens + all

6.3          Siemens Implemenatation

 

Definition of ACL broadcast / multicast (+ implications to X2S)

pull; push, subscribe (just one predicate?)

 

 

 



[1] Except for communication between a service and a lookup service, see later on.

[2] HTTPU is a variant of HTTP which delivers messages on top of unreliable UDP.

[3] HTTPMU is a variant of HTTPU, which allows multicast communication.

[4] LEAP (short for Lightweight Extensible Agent Platform) is a platform extension of the JADE agent platform [JADE] and has been developed in the framework of the European Community project LEAP, which is a cooperation between Motorola, Telecom Italia Lab, University of Parma, Broadcom, British Telecommunications, ADAC and Siemens. It addresses the need for open infrastructures and services that support dynamic, mobile enterprises. For more details, see [LEAP].

[5] Quite similar to device and service discovery mechanisms provided by Jini or UPnP.

[6] The term ACL used in this context of FIPA inter-platform communication does not only consist of ACL messages, but also comprises FIPA envelopes.  

[7] It is assumed here, that global unique agent identifiers (GUID) conform to <agentname>@<hap-name> naming scheme.

[8] Note, that HTTPMU is based on UDP and therefore not reliable.