FOUNDATION FOR INTELLIGENT PHYSICAL AGENTS

 

 

FIPA TC Gateways Second Call For Technology

 

 

Document title

FIPA TC Gateways Second Call For Technology

Document number

f-out-00098

Document source

FIPA TC Gateways

Document status

Preliminary

Date of this status

2001/10/11

Submissions due by

2002/01/15

Contact

gateways@fipa.org

Change history

2001/10/11

Initial draft

 

 

 

 

 

 

 

 

 

© 2001 Foundation for Intelligent Physical Agents - http://www.fipa.org/

Geneva, Switzerland

Notice

Use of the technologies described in this specification may infringe patents, copyrights or other intellectual property rights of FIPA Members and non-members. Nothing in this specification should be construed as granting permission to use any of the technologies described. Anyone planning to make use of technology covered by the intellectual property rights of others should first obtain permission from the holder(s) of the rights. FIPA strongly encourages anyone implementing any part of this specification to determine first whether part(s) sought to be implemented are covered by the intellectual property of others, and, if so, to obtain appropriate licenses or other permission from the holder(s) of such intellectual property prior to implementation. This specification is subject to change without notice. Neither FIPA nor any of its Members accept any responsibility whatsoever for damages or liability, direct or consequential, which may result from the use of this specification.

Foreword

The Foundation for Intelligent Physical Agents (FIPA) is an international organization that is dedicated to promoting the industry of intelligent agents by openly developing specifications supporting interoperability among agents and agent-based applications. This occurs through open collaboration among its member organizations, which are companies and universities that are active in the field of agents. FIPA makes the results of its activities available to all interested parties and intends to contribute its results to the appropriate formal standards bodies.

The members of FIPA are individually and collectively committed to open competition in the development of agent-based applications, services and equipment. Membership in FIPA is open to any corporation and individual firm, partnership, governmental body or international organization without restriction. In particular, members are not bound to implement or use specific agent-based standards, recommendations and FIPA specifications by virtue of their participation in FIPA.

The FIPA specifications are developed through direct involvement of the FIPA membership. The status of a specification can be either Preliminary, Experimental, Standard, Deprecated or Obsolete.More detail about the process of specification may be found in the FIPA Procedures for Technical Work. A complete overview of the FIPA specifications and their current status may be found in the FIPA List of Specifications. A list of terms and abbreviations used in the FIPA specifications may be found in the FIPA Glossary.

FIPA is a non-profit association registered in Geneva, Switzerland. As of January 2000, the 56 members of FIPA represented 17 countries worldwide. Further information about FIPA as an organization, membership information, FIPA specifications and upcoming meetings may be found at http://www.fipa.org/.

Contents

1     Glossary. 1

1.1          Abbreviations1

1.2          Definitions     1

2     Objectives4

3     Introduction       5

4     Instructions for Submitters. 6

4.1          Responding to this CFT    6

4.1.1             Timescales6

4.1.2             Notification of Intent     6

4.1.3             Separate Technology Proposals6

4.1.4             Completeness of Technology Proposals6

4.2          Confidential and Proprietary Information.. 6

4.3      Format of CFT Submissions6

4.3.1             General     6

4.3.2             Suggested Outline   6

4.4      How to Submit........ 7

4.5          Response to Submissions7

5     General Requirements for Submissions       8

6     Specific Requirements for Proposals.. 9

6.1          Problem Statement9

6.1.1             Definition of Possible Agent Platform Fragments9

6.1.2             Definition of Mechanisms for Managing Compounds             9

6.1.3             Usage of Existing Approaches             10

6.2          Relationship to Existing FIPA Specifications          11

6.3          Related Non-FIPA Documents11

6.4          Mandatory Requirements          11

6.5          Optional Requirements          12

6.6      Issues to be Discussed. 12

6.7      Other Information12

6.8          Timetable      12


1         Glossary

1.1        Abbreviations

 

Abbreviation

Expansion

AMS

Agent Management System

CDMA

Code Division Multiple Access

CDPD

Cellular Digital Packet Data

CFT

Call for Technology

DF

Directory Facilitator

FIPA

Foundation for Intelligent Physical Agents

GPRS

General Packet Radio Service

GSM

Global System for Mobile communications

HTTP

HyperText Transfer Protocol

IEEE

The Institute of Electrical And Electronics Engineers, Inc.

IIOP

Internet Inter-Orb Protocol

IrDA

Infrared Data Association

LAN

Local Area Network

PDA

Personal Digital Assistant

P2P

Peer-to-Peer

(FIPA) TC

(FIPA) Technical Committee

UML

Unified Modelling Language

UMTS

Universal Mobile Telecommunications System

UPnP

Universal Plug and Play

WAN

Wide Area Network

WAP

Wireless Application Protocol

WLAN

Wireless Local Area Network

WWAN

Wireless Wide Area Network

 

1.2        Definitions

Ad-hoc Network

An ad-hoc network is a network having a dynamic topology where nodes are free to move arbitrarily. Such networks are typically based on wireless communication technologies.

 

Agent

An agent is the fundamental actor in a domain. It combines one or more service capabilities into a unified and integrated execution model which can include access to external software, human users and communication facilities.

 

Agent Communication Language

A language with precisely defined syntax, semantics and pragmatics that is the basis of communication between independently designed and developed software agents.

 

Agent Communication Channel

A part of the Agent Platform which uses information provided by the Agent Management System to route messages between agents within the Agent Platform and to agents that reside on other Agent Platforms.

 

Agent Management System

A part of the Agent Platform which manages the creation, deletion, suspension, resumption, authentication and migration of agents on the Agent Platform and provides a white pages directory service for all agents resident on an Agent Platform.

 

Agent Platform

Provides an infrastructure in which agents can be deployed. An agent must be registered on a platform in order to interact with other agents on that Agent Platform or indeed other Agent Platforms. An Agent Platform consists of three capability sets: An Agent Communication Channel, an Agent Management System and at least one Directory Facilitator.

 

Communicative Act

A special class of actions that correspond to the basic building blocks of dialogue between agents. A communicative act has a well-defined, declarative meaning independent of the content of any given act. Communicate acts are modelled on speech act theory.

 

Content Language

The content of a FIPA message refers to whatever the communicative act applies. If, in general terms, the communicative act is considered as a sentence, then the content is the grammatical object of the sentence. This content can be encoded in any language, called the content language.

 

Directory Facilitator

A part of the Agent Platform that provides a yellow pages directory service for the agents. It stores descriptions of the agents and the services they offer.

 

Gateway

A gateway is a component residing between agent platforms. A gateway may relay messages between incompatible transports, may translate messages from one encoding to another, and may provide quality-of-service features supported by one party but not another.

 

Interaction Protocol

A common pattern of conversations used to perform some generally useful task. An interaction protocol is often used to facilitate a simplification of the computational machinery needed to support a given dialogue task between two agents.

 

Nomadic Application

A distributed application, with services that people can easily access while they are on the move, both at intermediate stops, and at arbitrary destinations. Typically people use mobile computers, PDAs, and intelligent phones along with different kinds of wireless communication networks, such as GSM, GPRS, UMTS, WLAN, Bluetooth, and IrDA to access the services of nomadic applications.

 

Message

An individual unit of communication between two or more agents. A message corresponds to a communicative act, in the sense that a message encodes the communicative act for reliable transmission between agents. Note that communicative acts can be recursively composed, so while the outermost act is directly encoded by the message, taken as a whole a given message may represent multiple individual communicative acts.

 

Message Transport Connection

A physical instance of a peer-to-peer data communication connection between Agent Communication Channels and agents, over which a Message Transport Protocol can be run.

 

Message Transport Protocol

An instance of a network transport protocol that is used to carry out the physical transfer of messages between two Agent Communication Channels, between an agent and a remote or local Agent Communication Channel, or between two agents.

 

Message Transport Service

A service provided by the Agent Platform to which the agent is attached. The Message Transport Service supports the transportation of Agent Communication Language messages between agents. On any given Agent Platform, the Message Transport Service is provided by the Agent Communication Channel.

 

Ontology

An explicit specification of the structure of a certain domain (for example, e-commerce, sport, etc.). For the practical goals of FIPA (that is enabling development and deployment of inter-operable agent-based applications), this includes a vocabulary (that is, a list of logical constants and predicate symbols) for referring to the subject area and a set of logical statements expressing the constraints existing in the domain and restricting the interpretation of the vocabulary. Ontologies therefore provide a vocabulary for representing and communicating knowledge about some topic and a set of relationships and properties that hold for the entities denoted by that vocabulary.

 

Wireless Local Area Network

The transmission media of a Wireless Local Area Network is a radio signal (typically in the frequency bands 900 MHz and 2.4 GHz) with very limited coverage area, such as a department or a campus. Typical features of WLAN are the following: line rate is between 2 Mbits/s and 10 Mbits/s and roundtrip time is about 3 ms. An example of WLAN is an IEEE 802.11 based network.

 

Wireless Wide Area Network

The transmission media of a Wireless Wide Area Network is a radio signal (typically in the frequency bands 450 MHz, 900 MHz and 1.8 GHz) with large coverage area, such as a city or a country. Typical features of WWAN are the following: line rate is below 64 Kbits/s and roundtrip time is about 400 – 500 ms. Examples of WWAN are GPRS, CDPD, and CDMA.

 


2         Objectives

The objective of this Call for Technology (CFT) is to solicit proposals that will enhance interoperability between FIPA agents operating in ad-hoc environments. Submissions, in the form of technology artefacts (including but not limited to specifications, source code and products), shall address one or more of the following requirements (in part or completely):

 

·         Definition of possible agent platform fragments, which can form dynamically a compound.

 

·         Definition of mechanisms and protocols for agent platform fragments to build, release, join and leave compounds.

 

·         Usage of existing approaches which provide support on different levels (e.g., Bluetooth ad-hoc networks, JXTA P2P approach).

 

For further details, see Section 5 and 6 of this document.


3         Introduction

The results of current developments in both wireless data communications and mobile computers are being combined to facilitate a new trend: nomadic computing. Users can significantly benefit from nomadic computing in many situations. Examples include electronic commerce, information retrieval and mobile team support.

 

An ad-hoc network is a network having a dynamic topology where nodes are free to move arbitrarily. Such networks are typically based on wireless communication technologies such as Infrared, Bluetooth and Wireless LAN and may use technologies like Jini and UPnP to enable new applications in the area of local range networks. Mobile devices, such as mobile phones and PDAs, equipped with that technology, make the communication of two devices or the establishing of an ad-hoc group with more than two devices possible.

 

Once working in that ad-hoc and short-range area, probably a device has no wide-range connection (e.g. there is no coverage at the moment or a user does not want to establish such a connection because of the cost). In that context, the agents on two mobile devices, originally created on different platforms, have to discover each other and to build an ad-hoc compound[1] allowing them to communicate with each other. A compound can be based on:

 

·         either two different complete agent platforms (one agent platform on each device), or

 

·         two fragments[2] of different agent platforms, or

 

·         a complete platform and one fragment from a different platform.

 

These three cases are also applicable if there are more than two devices involved in building an ad-hoc compound. Compounds also have to be robust enough to handle the migration (i.e., leaving) of devices.

 

FIPA has already addressed some of the problems related to wireless communication in the FIPA Nomadic Application Support Specification [FIPA00014], FIPA Device Ontology Specification [FIPA00091], FIPA Message Buffering Service Specification [FIPA00092], and FIPA Messaging Interoperability Services Specification [FIPA00093]. However, further specifications are required to address a number of issues in order to facilitate interoperability between agents operating on different platforms in ad-hoc environments.


4         Instructions for Submitters

4.1        Responding to this CFT

4.1.1          Timescales

See Table 3 in Section 6.8, Timetable for submission deadlines.

4.1.2          Notification of Intent

Individuals or companies must notify the FIPA secretariat (secretariat@fipa.org) of their intention to respond to this CFT (see Table 3).

4.1.3          Separate Technology Proposals

A submitter may respond to any or all parts of this CFT. Each technology will be evaluated independently by FIPA TC Gateways. It should be noted that a given technology (theoretical or tested and proven work) may support two or more parts of the CFT.

4.1.4          Completeness of Technology Proposals

Proposals for each separate technology item need not be complete. However, reasons for not being complete must be clearly stated.

4.2        Confidential and Proprietary Information

The FIPA specification adoption process is an open process. Responses to this CFT become public documents of the FIPA and are available to members and non-members alike for perusal. No confidentiality or proprietary information of any kind will be accepted in a submission to this CFT.

4.3        Format of CFT Submissions

This section provides guidance on how to structure a submission.

4.3.1          General

·         Submissions must be written in English.

 

·         Submissions should be concise and easy to read.

 

·         Submitted documentation should be directly relevant to the technology requested in the CFT.

 

·         The file format of the submissions should be one of plain text, HTML, PDF, Microsoft Word or PostScript.

4.3.2          Suggested Outline

A two-part structure for a submission is suggested:

 

PART I

·         Submission contact point, including name, postal address, affiliation, email address, telephone number, and fax number.

 

·         Completeness of the submission (see Section 4.1.4, Completeness of Technology Proposals).

 

·         Overview of the submission.

 

PART II

·         Proposed specification(s).

4.4        How to Submit

Submitters should send an electronic version of their submission to the FIPA Secretariat (secretariat@fipa.org) and a copy to the FIPA TC Gateways mailing list (gateways@fipa.org).

4.5        Response to Submissions

Feedback on submissions will be provided in accordance with the timescales shown in Table 3. The response will be send to the email and postal address provided by the submitter.


5         General Requirements for Submissions

Proposals should not conflict with FIPA Abstract Architecture Specification [FIPA00001] and with other FIPA specifications (see Table 2).

 

Note the following when writing a proposal:

 

·         Any conflicts must be clearly identified, along with reasons for them.

 

·         Emphasis should be put on the use of reusable components.

 

·         Proposals shall preserve maximum implementation flexibility and interoperability.

 

·         The use of UML modelling is desirable, but not mandatory.

 

·         Proposals can be based on theoretical work or tested, proven work.

 


6         Specific Requirements for Proposals

Proposals shall describe solutions that enable usage of FIPA agent platforms in ad-hoc environments. Some examples of possible scenarios follow:

 

·         Fragments building a compound. Two visitors of a conference, both having a Bluetooth enabled small device running agents on it, would like to exchange some information, e.g. business cards. Because of the limited resources of the devices, only one device has DF functionality. After both devices are close enough to each other the underlying ad-hoc network connection will be established automatically by Bluetooth. The network enables the agents on both devices to discover each other. However, the device without DF functionality must use the remote DF to advertise its own services and to find out which services are provided by agents on the device with the DF. In the case that no DF functionality is available the advertisement and finding of services needs other mechanisms.

 

·         Fragment leaves a compound. There is an ad-hoc network consisting of three WLAN enabled small devices running agents on them. Because of the limited resources of the devices, only one device has DF functionality. If the device with the DF functionality is leaving the ad-hoc network, special mechanisms for advertisement and finding of services inside the remaining compound are needed.

 

Proposed technology must be independent of specific implementation technologies and specifications. Additionally, they must be generic as possible. The proposals do not have to be based on compounds and fragments, but any proposals solving the problem will be considered. The concepts of compound and fragment are only used for illustrating the problem.

6.1        Problem Statement

In an ad-hoc network, devices use wireless technologies to communicate in a peer-to-peer (i.e., device-to-device) fashion.  Thus, agents on two mobile devices, originally created on different platforms, need to discover each other and build an ad-hoc compound that allows each agent to communicate with the other.

 

In order to manage (e.g., start) an agent, the current FIPA specifications require access to an AMS [FIPA00023]. In an ad-hoc environment, it might be possible that no AMS is accessible. Furthermore, because of limited memory resources, the device may not be able to host an AMS. Therefore, a solution for managing agents with or without access to an AMS is needed. There is a similar issue when no DF is accessible but there is a need to discover services.

 

Another potential problem in ad-hoc environments concerns the dynamic topology of the network. This includes issues regarding graceful communication degradation. For example, the remote node hosting the AMS, DF or any other peer agent or service moves out of proximity.

 

Solutions should consider the limited bandwidth available in ad-hoc environments and the limited battery power and memory issues on small mobile devices. Proposals that address security in such environments are also desired.

6.1.1          Definition of Possible Agent Platform Fragments

Current FIPA specifications require many mandatory functionalities. In ad-hoc environments such functionality may not be required. For example, if there is no local DF in the platform it might be possible to use a remote one. Such a subset of a FIPA-compliant agent platform is called a fragment.  A minimal fragment of an agent platform may consist solely of an agent and its communication mechanism.  A more comprehensive fragment may consist of an agent, its communication mechanism, and an AMS (and/or DF).

6.1.2          Definition of Mechanisms for Managing Compounds

In ad-hoc environments, the agents on two mobile devices, originally created on different platforms, have to discover each other and to build an ad-hoc compound allowing them to communicate with each other. A compound can be based on:

 

·         either two different complete agent platforms (one agent platform on each device), or

 

·         two fragments of different agent platforms, or

 

·         a complete platform and one fragment from a different platform.

 

These three cases are also applicable if there are more than two devices involved in building an ad-hoc compound. Compounds also have to be robust enough to handle the migration (leaving) of devices. Mechanisms should at least include building, releasing and merging compounds as well as fragments joining and leaving compounds.

6.1.3          Usage of Existing Approaches

For all proposals, it is highly recommended to take existing approaches into account, such as Plug and Play mechanisms like Jini and UPnP and P2P approaches.


6.2        Relationship to Existing FIPA Specifications

Table 1 and Table 2 identify existing FIPA Specifications which have a relationship to technologies requested in this CFT. All the specifications can be retrieved from http://www.fipa.org/specs/.

 

Specification Number

Title

FIPA00001

FIPA Abstract Architecture Specification

FIPA00014

FIPA Nomadic Application Support Specification

FIPA00023

FIPA Agent Management Specification

FIPA00092

FIPA Message Buffering Specification

FIPA00091

FIPA Device Ontology Specification

FIPA00093

FIPA Messaging Interoperability Services Specification

 

Table 1: Referenced Relevant FIPA Specifications

 

Specification Number

Title

FIPA00067

FIPA Agent Message Transport Service Specification

FIPA00075

FIPA Agent Message Transport Protocol for IIOP Specification

FIPA00076

FIPA Agent Message Transport Protocol for WAP Specification

FIPA00084

FIPA Agent Message Transport Protocol for HTTP Specification

 

Table 2: Non-Referenced Relevant FIPA Specifications

6.3        Related Non-FIPA Documents

The Official Bluetooth Website, 2001. Available from World Wide Web: http://www.bluetooth.com.

 

The Infrared Data Association. IrDA homepage, 2001. Available from World Wide Web: http://www.irda.org.

 

IEEE Std 802.11-1999, Information Technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements—Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Press, New York, USA, 1999.

 

IEEE Std 802.11b-1999, Supplement to Information Technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements—Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: High-speed Physical Layer Extension in the 2.4 Ghz Band, IEEE Press, New York, USA, 1999

 

Java Agent Services Web page, 2001. Available from World Wide Web: http://www.java-agent.org/

 

K. Arnold, O. Sullivan, R. Scheifler, J. Waldo, and A. Wollrath. The Jini Specification. Addison-Wesley, 1999.

 

Universal Plug and Play Forum. Universal Plug and Play Forum Home Page, 2001. Available from World Wide Web: http://www.upnp.org/

 

Peer-to-Peer Working Group. Peer-to-Peer Working Group home page, 2001.  Available from World Wide Web: http://www.peer-to-peerwg.org/

 

Steffen Rusitschka: Using Plug&Play technologies by agent systems, diploma thesis in German, Siemens AG and University of Marburg, Germany, January 2001.

6.4        Mandatory Requirements

None.

6.5        Optional Requirements

None.

6.6        Issues to be Discussed

Proposals should discuss potential impact on FIPA specifications. In addition, proposals should discuss possible usage of existing approaches in the ad-hoc and P2P world which provide support on different levels

6.7        Other Information

None.

6.8        Timetable

The timetable for this CFT is given in Table 3. Note that FIPA may, in certain circumstances, extend deadlines while the CFT is running, or may elect to have more than one revised submission step.

 

Action

Latest Date

Notification of intent to submit

2001/12/31

Submissions due

2002/01/15

Proposal presentations and discussions

2002/02 (FIPA 24)

Feedback to submitters

2002/03/15

Preliminary specification

2002/10 (FIPA 27)

Experimental specification

2003/04 (FIPA 29)

 

Table 3: Timescales



[1] A compound need not necessarily form a complete platform.

[2] A fragment of a distributed agent platform is a non-complete FIPA-compliant agent platform. The definition of a fragment will also be influenced by the minimal FIPA and FIPA compliance level specification. E.g., a fragment of an agent platform could be just an agent and its runtime environment.