1 Glossary
1.1 Abbreviations
|
Abbreviation |
Expansion |
|
ACC |
Agent Communication Channel |
|
ACL |
Agent Communication Language |
|
AMS |
Agent Management System |
|
AP |
Agent Platform |
|
CCL |
Common Command Language |
|
CFT |
Call for Technology |
|
CL |
Content Language |
|
DF |
Directory Facilitator |
|
FAB |
FIPA Architecture Board |
|
FIPA |
Foundation for Intelligent Physical Agents |
|
GPRS |
General Packet Radio Service |
|
GSM |
Global System for Mobile communications |
|
GUID |
Globally Unique Identifier |
|
HTTP |
HyperText Transfer Protocol |
|
IIOP |
Internet Inter-Orb Protocol |
|
KIF |
Knowledge Interchange Format |
|
LAN |
Local Area Network |
|
MTM |
Message Transport Model |
|
MTP |
Message Transport Protocol |
|
MTS |
Message Transport Service |
|
PDA |
Personal Digital Assistant |
|
RDF |
Resource Description Framework |
|
(FIPA) TC |
(FIPA) Technical Committee |
|
TCP/IP |
Transmission Control Protocol/Internet Protocol |
|
UMTS |
Universal Mobile Telecommunications System |
|
WAN |
Wide Area Network |
|
WAP |
Wireless Application Protocol |
|
(FIPA) WG |
(FIPA) Working Group |
|
WLAN |
Wireless Local Area Network |
|
WWAN |
Wireless Wide Area Network |
1.2 Definitions
Action
A basic construct which represents some activity which an agent may perform. A special class of actions is the communicative acts.
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
That part of a communicative act which represents the domain dependent component of the communication. Note that "the content of a message" does not refer to "everything within the message, including the delimiters", as it does in some languages, but rather specifically to the domain specific component. In the Agent Communication Language semantic model, a content expression may be composed from propositions, actions or Identifying Referring Expressions.
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.
Conversation
An ongoing sequence of communicative acts exchanged between two (or more) agents relating to some ongoing topic of discourse. A conversation may (perhaps implicitly) accumulate context that is used to determine the meaning of later messages in the conversation.
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, and UMTS 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 Content
See Content.
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.
Ontology Name
The ontologies referred to by agents that can be provided by different ontology servers. Consequently, these ontology names are constructed from the ontology agent name and the ontology logical name (given by the ontology designer, for example, "car").
Roaming
An action where a mobile terminal moves from one network coverage area to another. This action may take place, for example, when the mobile terminal moves from a GSM network operated by one operator to a GSM network operated by a different operator, or when the mobile terminal moves from a GPRS network to a wireless local area network.
WAP
The Wireless Application Protocol is wireless application architecture developed by an industrial consortium called the WAP Forum. The architecture is based on client – proxy – server model, and it addresses the problems created by accessing Internet services via low bandwidth wireless protocols and low-end mobile devices.
Wireless Environment
An agent communication environment, where at least one component of the communication media is implemented with radio signals.
Wireline Environment
An agent communication environment, where all components of the communication media are implemented with wired connections.
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 CFT (CFT) is to solicit proposals that will enhance interoperability between FIPA agents operating in wireless and wireline network domains. Submissions may also address issues relating to interoperability between wireless network domains. Figure 1 shows the intended operating environment and a FIPA Gateway as a bridge to support agent communication between the 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):
· support for disconnected operation mode,
· support for roaming from one gateway to another,
· use of profiles to specify the capabilities of gateways and mobile devices, and,
· technology for bit-efficient representation of FIPA message parts, especially the envelope and the content of the ACL message.
For further details see Section 5 and 6 of this document.
Figure 1: FIPA Gateway Operating Environments
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. There are a lot of situations in which users can significantly benefit from nomadic computing. Examples include electronic commerce, information retrieval and mobile team support.
Compared to today’s traditional distributed systems, the nomadic computing environment is very different in many respects. Bandwidth, latency, delay, error rate, quality of display, and other non-functional parameters may change dramatically when a nomadic end-user moves from one location to another and thus from one computing environment to another, for example, from a wireline LAN to a UMTS network.
The variety of mobile workstations, handheld devices and smart phones, which allow nomadic end-users to access Internet services, is increasing rapidly. The capabilities of mobile devices range from very low performance equipment (for example, PDAs) up to high performance laptop PCs. All these create new demands for adaptability of Internet services. For example, PDAs cannot display properly high quality images, and as nomadic end-users will be charged based on the amount of data transmitted over the network (be it GPRS or UMTS), they will have to pay for bits that are totally useless for them.
FIPA has already addressed some of the problems in the FIPA Nomadic Application Support Specification [FIPA00014] and FIPA ACL Representation in Bit-Efficient Encoding Specification [PC00069], however further specifications are required to address a number of issues in order to facilitate interoperability between agents operating on different platforms in nomadic application environments.
Almost any application in the FIPA environment can be a nomadic application. The nomadic application environment consists of two clearly separate domains: a wireless and a wireline network environment. Current FIPA specifications do not define how interoperability can be achieved between agents operating in these two domains. Therefore, implementation specific and propriety solutions are the only option at present.
This CFT is part of the process of the development of FIPA specifications covering high level interoperability between agent platforms in wireless and wireline domains. Although detailed submissions to address interoperability issues such as the transformation of message encoding representations, protocols and data representations are not required, the existence of such issues must be recognised. Therefore submissions must indicate how and when interaction with such functions will take place.
Annex A of FIPA Nomadic Application Support Specification [FIPA00014] contains a detailed informative scenario description. Other examples of possible scenarios follow:
· An open FIPA-compliant infrastructures and agent-based services which support dynamic, mobile enterprises: Mobile team management applications use wireless connections to cover large geographical areas. In-the-van crew get orders, synchronise their tasks, retrieve documentation, interact with other team members to co-operate, get help and information and exchange tasks 'on the fly' according to their preferences and location, supported in all these operations by pro-active agents running on hand-held devices.
· Decentralised, real-time control of a UMTS network using distributed intelligent agents which have local node knowledge: The focus is on the implementation of specific resource allocation strategies on an experimental network platform as a distributed system of interacting software agents under decentralised control. To enable near real-time decisions to be obtained through agent collaboration, a mechanism is required for seamless, efficient communication with agents executing within the wireline and wireless domains.
· NEOs (non-combatant evacuation operations): NEOs are conducted to evacuate civilian non-combatants and non-essential military personnel from locations in a foreign (host) nation during time of endangerment (such as war, civil unrest, or natural disaster) to a designated safe location. In general, a NEO may require the deployment of mobile wireless networks to enable ground forces to communicate with a command centre typically located either on a command ship or at a fixed ashore location. Fixed command locations will probably contain computer systems and traditional wireline networks.
Proposed technology must be independent of specific implementation technologies and specifications. They must be generic and as a minimum they must support current FIPA MTPs and FIPA message representations (envelope, ACL, and content languages). In addition, they may support proprietary MTPs and message representations.
4 Instructions for Submitters
4.1 Responding to this CFT
4.1.1 Timescales
See Table 3 in Section 6.9, 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, fax number.
· Completeness of the submission (see Section 4.1.4, Completeness of Technology Proposals):
- State which of the items in Section 6.2are explicitly addressed by your submission.
· Clearly explain the status of the work at the time of submission, in terms of one of the following:
- Theoretical model;
- Designed;
- Partially implemented;
- Implemented but not fully tested;
- Implemented with limited evaluation;
- Commercial implementation;
- Other (please specify).
· 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
6.1 Domains of Interest
Proposals shall describe solutions that work between wireless and wireline domain and between two wireless domains.
6.2 Problem Statement
Almost any application in the FIPA environment can be a nomadic application. The nomadic application environment consists of two clearly separate domains: a wireless environment and a wireline network environment. Current FIPA specifications do not define how interoperability can be achieved between agents operating in these two domains, thus implementation specific and propriety solutions are required.
In the following examples of issues relating to interoperability, Agent A operates in the wireless network environment and agent B operates in the wireline network environment:
· Agent A is operating in a mobile host that has an intermittent connection to a wireline network domain.
· Agent A resides in a mobile host that may change frequently its access point to the wireline network.
In each of the above cases the question can be raised: "How do agent A and agent B interact and continue to interact with each other?" Similar problems may exist in environments where there are two different kinds of wireless networks.
6.2.1 Support for Disconnected Mode of Operation
When a mobile device is disconnected from the network for any reason (either by choice or circumstance), there is a need to ensure that any inter-agent communication is not abruptly terminated, that is, no messages are effectively lost or corrupted, and that inter-agent communication can readily be re-established once the mobile device is reconnected. Note that in certain circumstances it may be desirable to reject, upon reconnection, some or all of the messages that were transmitted during the period of disconnection. Reliable transport mechanisms that provide timely and/or guaranteed delivery of agent messages are therefore required.
6.2.2 Roaming from One Gateway to Another
When a mobile device roams from one wireless network (for example, UMTS; public Internet-access, which is operated by a public operator) to a different kind of wireless network (for example, WLAN; private Internet-access, which is operated by a private company) there is a disconnection. The mobile device is disconnected from for example, UMTS and connected to for example, WLAN.
From the point of view of an agent (either running on the roaming mobile device, or communicating with an agent running on the roaming mobile device), roaming can introduce some or all of the following problems:
· disconnection s (see Section 6.2.1, Support for Disconnected Mode of Operation),
· the transport address of a roaming agent may change,
· mobile terminated messages may get lost,
· characteristics of the new network may need significant changes to gateway configuration,
· selection of the most suitable gateway (based on the capabilities of the available gateways and the current environment), and,
· handover may cause additional delays.
Mechanisms are required to minimise/nullify the impact of the above.
6.2.3 Profiles that Specify Capabilities of Gateways and Mobile Devices
In order for reduce the potential for conflict between the capabilities of gateways and mobile devices, some form of capability assessment, location and matching is required.
6.2.4 Bit-Efficient Representation of Information
As wireless bandwidth is currently a precious commodity, bit-efficient representations of the envelope and the content of the ACL message are needed. Note that FIPA has some relevant work in progress, namely the FIPA Agent Message Transport Envelope Representation in Bit-Efficient Encoding Specification [PC00088]. As that specification currently has preliminary status, it is anticipated that it will be revised as a result of responses to this Call for Technology.
6.3 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 |
|
FIPA00069 |
FIPA ACL Message Representation in Bit-Efficient Encoding Specification |
|
PC00088 |
FIPA Agent Message Transport Envelope Representation in Bit-Efficient Encoding Specification |
Table 1: Referenced Relevant FIPA Specifications
|
Specification Number |
Title |
|
FIPA00007 |
FIPA Content Language Library Specification |
|
FIPA00023 |
FIPA Agent Management Specification |
|
FIPA00061 |
FIPA ACL Message Structure Specification |
|
FIPA00067 |
FIPA Agent Message Transport Service Specification |
|
FIPA00070 |
FIPA ACL Message Representation in String Encoding Specification |
|
FIPA00071 |
FIPA ACL Message Representation in XML Specification |
|
FIPA00075 |
FIPA Agent Message Transport Protocol for IIOP Specification |
|
FIPA00076 |
FIPA Agent Message Transport Protocol for WAP Specification |
Table 2: Non-Referenced Relevant FIPA Specifications
6.4 Related Non-FIPA Documents
WAP-1000, Wireless Application Protocol Architecture Specification. WAP Forum, June 2000.
CORBA/IIOP 2.3.1 Specification (Formal/99-10-07). Object Management Group, October 1999.
HyperText Transfer Protocol Specification. World Wide Web Consortium.
6.5 Mandatory Requirements
None.
6.6 Optional Requirements
None.
6.7 Issues to be Discussed
Proposals should discuss potential impact on FIPA specifications. In addition, proposals should discuss interrelationship with other gateway services, such as application data conversion and protocol conversion.
6.8 Other Information
None.
6.9 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 |
2000/12/24 |
|
Submissions due |
2000/12/31 |
|
Presentation and discussion of submissions |
2001/01/29 - 2001/02/02 @FIPA 20 meeting in Phoenix Arizona, USA |
|
Feedback to submitters |
2001/02/28 |
|
Preliminary specification(s) |
2001/07 |
|
Experimental specification(s) |
2002/01 |
Table 3: Timescales