FOUNDATION FOR INTELLIGENT PHYSICAL AGENTS

 

 

FIPA Nomadic Application Support Specification

 

 

 

 

 

 

 

 

 

 

© 2000 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 17countries 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     Scope. 3

2     General Analysis. 3

2.1      Overview. 3

2.2      Monitoring and Controlling Quality of Service. 3

2.3      Negotiation of Message Transport Requirements. 3

2.3.1      Negotiation About Message Transport Protocols. 3

2.3.2      Negotiation About Message Representation. 3

3     Nomadic Application Support Ontology. 3

3.1      Object Descriptions. 3

3.1.1      Quality of Service Description. 3

3.1.2      Rate Value. 3

3.1.3      Time Value. 3

3.1.4      Probability Value. 3

3.1.5      Change Constraint3

3.1.6      Time Constraint3

3.1.7      Communication Channel Description. 3

3.1.8      Transport Protocol Description. 3

3.1.9      Transport Protocol Selection. 3

3.1.10    Message Representation Description. 3

3.1.11    Message Representation Selection. 3

3.2      Function and Predicate Descriptions. 3

3.2.1      Request Monitoring Information. 3

3.2.2      Subscribe to Changes. 3

3.2.3      Open Communication Channel3

3.2.4      Close Communication Channel3

3.2.5      Activate a Message Transport Protocol3

3.2.6      Deactivate a Message Transport Protocol3

3.2.7      Select a Message Transport Protocol3

3.3      Exceptions. 3

3.3.1      Not Understood Exception Propositions. 3

3.3.2      Refusal Exception Propositions. 3

3.3.3      Failure Exception Propositions. 3

4     Registration of the Control Agent and Monitor Agent with the DF. 3

5     Scenarios. 3

5.1      Registration with a DF. 3

5.2      Negotiating Message Transport Protocols. 3

5.3      Negotiating Message Representations. 3

5.4      Message Exchange Over a WAP Message Transport Protocol3

5.4.1      Message Exchange Activation by an Agent in a Mobile Host3

5.4.2      Message Exchange Termination to an Agent in a Mobile Host3

6     Informative Annex A — Paramedic Scenario. 3

6.1      Overview. 3

6.2      Seamless Roaming. 3

6.2.1      Disconnection and Reconnection of an Message Transport Connection. 3

6.2.2      Example Negotiation of a Message Transport Protocol3

6.2.3      Example Negotiation of a Message Representation. 3

7     References. 3

1         Scope

This document is part of the FIPA specifications and deals with agent middleware to support applications in nomadic environment. The environment of mobile computing is very different compared to today’s environment of traditional distributed systems in many respects. Bandwidth, latency, delay, error rate, interference, interoperability, computing power, quality of display, among other things may change dramatically as a nomadic end-user moves from one location to another. All these cause new demands for adaptability of data services.

 

Adaptability to the changes in the environment of nomadic end-users is an important issue. A nomadic end-user confronted with these circumstances would benefit from having the following functionality provided by the infrastructure: information about expected performance, agents controlling over the transfer operations, a condition-based control policy, capability provided by agents to work in a disconnected mode, advanced error recovery methods, and adaptability.

 

This specification gives an overview of the Nomadic Application Support area and contains specifications for:

 

·         Monitor Agent (MA) functionality,

 

·         Control Agent (CA) functionality, and,

 

·         An ontology for representing the quality of service of the Message Transport Service in the context of nomadic application support.

 

In addition, two other FIPA specifications are related to Nomadic Application Support: FIPA Agent Message Transport Protocol for WAP Specification [FIPA00076] and FIPA ACL Message Representation in Bit-Efficient Encoding Specification [FIPA00069].

 

2         General Analysis

2.1        Overview

The results of current developments in both wireless data communications and mobile computers are being combined to facilitate a new trend: nomadic computing. 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 (such as PDAs) up to high performance laptop PCs. All these devices create new demands for adaptability of Internet services. For example, PDAs cannot display properly high quality images and as nomadic end-users may be charged based on the amount of data transmitted over the GPRS-UMTS network, they may have to pay for bits that are totally useless to them.

 

Confronted with these circumstances, the nomadic end-user would benefit from having the following functionality provided by the infrastructure: information about expected performance, agent monitoring and controlling the transfer operations, and adaptability.

 

The ability to automatically adjust to changes in a transparent and integrated fashion is essential for nomadicity; nomadic end-users are usually professionals in areas other than computing. Furthermore, today’s mobile computer systems are already very complex to use as productivity tools. Thus, nomadic end-users need all the support that a FIPA agent-based distributed system can deliver and adaptability to the changes in the environment of nomadic end-users is an important issue.

 

FIPA uses the Wireless Application Protocol (WAP) [WAP99] as its wireless Message Transport Protocol (MTP - see [FIPA00076]). The WAP Forum has developed industry-wide specifications for low bandwidth wireless services (such as GSM, GPRS, etc.) and wireless devices (such as mobile telephones and personal digital assistants). The WAP specification address the characteristics of wireless networks by adapting low bandwidth wireless services and low-end mobile devices to the special requirements of information services. The WAP specification defines a set of standard components that can be used in agent message communication, such as standard data formats and standard data communication protocols.

 

The adaptation of applications to various nomadic computing environments is an important area. There are several tasks that agents need to carry out during application adaptation:

 

1.       Selection of MTP and Message Transport Connection (MTC) to be used for agent communication.

 

2.       Selection of an ACL and content language representation to be used for agent communication.

 

3.       Provision of support for application agents to carry out adaptation of application data, such as still images, video and audio, XML, etc. Today’s Internet application data (such as multimedia content) are designed with high performance desktop PCs and high quality displays in mind. Therefore, the application data is frequently unsuitable for nomadic computing using wireless wide-area networks and low performance mobile devices, and hence requires modification.

 

4.       Communication between agents performing adaptation.

 

The FIPA Nomadic Application Support specifications define agent middleware to:

 

·         Monitor and control an MTP and the underlying MTC, and,

 

·         An ontology for representing the quality of service of the Message Transport Service in the context of nomadic application support.

In addition, this specification gives examples of the use of the above scenarios.

 

2.2        Monitoring and Controlling Quality of Service

The functions required to carry out monitoring and controlling for quality of service can be split into several specific tasks:

 

1.       Observing the quality of service of MTPs and MTCs,

 

2.       Measuring (if there are no other means to obtain the required information) the quality of service of an MTP and MTC,

 

3.       Collecting information from the observing and measuring sources,

 

4.       Analysing the information, and,

 

5.       Controlling an MTC and selecting an MTP.

 

Based on this division, the agent middleware consists of the following logical agents (see Figure 1):

 

·         A Monitor Agent (MA) which carries out tasks 1 through 4, and,

 

·         A Control Agent (CA) which carries out task 5.

 

 

Figure 1: Reference Model of Agent based Adaptation

 

The most appropriate configuration of MAs and CAs is that there is at least one pair in each AP involving adaptation. The MA may measure the actual quality of service of an MTC, if the network running an MTC does not provide users with required performance data[1].

 

An MA may:

 

·         Consist of network-service-specific components that collect raw performance data at fixed intervals,

 

·         Provide a repository for the measurement data collected,

 

·         Perform first level analysis of the collected data, and,

 

·         Send the results of the analysis to CA, if requested to do so.

 

A CA may:

 

·         Manage (establish, close, suspend, activate, etc.) an MTC[2].

 

In some cases there is a need for MAs and CAs in heterogeneous APs to communicate with each other; therefore, interaction protocols and ontologies to achieve this are specified in this document.

 

2.3        Negotiation of Message Transport Requirements

There are several mechanisms that can determine the MTP, message representation and content language to use between communicating entities:

 

·         Communicating entities know a peer entity’s preferences beforehand and use them.

 

·         The activating entity tries to use a method and if the peer entity is not capable of using the suggested method, then the activating entity may try another one (and so on).

 

·         The communicating entities negotiate about a method to be used.

 

2.3.1          Negotiation About Message Transport Protocols

Previous FIPA specifications have implicitly assumed that the MTC is operational all the time (meaning that the MTC has been established before the agent message exchange and that it is reliable). However, this is not always the case within a nomadic environment.

 

A CA can activate the selection of an MTP or an agent can propose an MTP to a CA and it is the responsibility of the CA to either accept or reject the proposal based on whether it is possible to use the proposed MTP. CAs negotiate with peer CAs to use proposed MTPs which is illustrated in Figure 2.

 

 

Figure 2: Control Agents Negotiating About a Message Transport Protocol

 

CAs use the FIPA-Propose interaction protocol [FIPA00036] and the use action to negotiate about an MTP. An example negotiation is given in section 5.2, Negotiating Message Transport Protocols.

 

2.3.2          Negotiation About Message Representation

In the environment of nomadic applications, it may be necessary to switch from one ACL representation to another; for example, when a mobile host roams from a wireline network to a wireless network. Application agents may use the FIPA-Propose interaction protocol and the use action to negotiate about the representation of ACL. Examples of this negotiation are given in section 5.3, Negotiating Message Representation.

3         Nomadic Application Support Ontology

The FIPA-Nomadic-Application ontology is a combination of FIPA-MTS-QoS, FIPA-Communication-Management, and FIPA-Message-Representation ontologies.

3.1        Object Descriptions

This section describes a set of frames, that represent the classes of objects in the domain of discourse within the framework of the FIPA-Nomadic-Application ontology.

 

The following terms are used to describe the objects of the domain:

 

·         Frame. This is the mandatory name of this entity, that must be used to represent each instance of this class.

 

·         Ontology. This is the name of the ontology, whose domain of discourse includes the parameters described in the table.

 

·         Parameter. This is the mandatory name of a parameter of this frame.

 

·         Description. This is a natural language description of the semantics of each parameter.

 

·         Presence. This indicates whether each parameter is mandatory or optional.

 

·         Type. This is the type of the values of the parameter: Integer, Word, String, URL, Term, Set or Sequence.

 

·         Reserved Values. This is a list of FIPA-defined constants that can assume values for this parameter.

 

3.1.1          Quality of Service Description

This type of object represents the quality of service of the transport protocol or communication channel.

 

Frame Ontology	qos FIPA-MTS-QoS
Parameter	Description	Presence[3]	Type	Reserved Values
line-rate	The bandwidth in one direction over the link.	Optional	rate-value
throughput	The number of user data bits successfully transferred in one direction across the link[4]. Successful transfer means that no user data bits are lost, added or inverted in transfer.	Optional	rate-value
throughput-std-dev	The current standard deviation of the throughput within a time unit.	Optional	rate-value
rtt	The round trip time which is the time required for a data segment to be transmitted to a peer entity and a corresponding acknowledge­ment sent back to the originating entity.	Optional	time-value
rtt-std-dev	The standard deviation of the round-trip time within a time unit.	Optional	time-value
delay	The (nominal) time required for a data segment to be transmitted to a peer entity.	Optional	time-value
delay-std-dev	The standard deviation of the delay time within a time unit.	Optional	time-value
mean-up-time	The expected uptime of an established link.	Optional	time-value
omission-rate	The probability that a data segment is not transmitted correctly over a link.	Optional	probability-value
ber	The ratio of the number of bit errors to the total number of bits transmitted in a given time interval[5].	Optional	probability-value
frame-error-rate	The probability that a data segment is not transmitted correctly over a link.	Optional	probability-value
conn-setup-delay	The (sampled) delay to establish a connection between communicating entities.	Optional	time-value
conn-setup-failure-prob	The ratio of total call attempts that result in call setup failure to the total call attempts in a population of interest.	Optional	probability-value
status	The connectivity status of the link. Connected means that there (at least) logical connection between communicating entities. Disconnected means that there is no connection between communicating entities, and the communicating entities are not establishing a connection at the moment. Connecting means that there is no connection between communicating entities, but they are currently establishing a connection between them.	Optional	Word	Connected Disconnected Connecting

3.1.2          Rate Value

This type of object represents a data transfer value.

 

Frame Ontology	rate-value FIPA-MTS-QoS
Parameter	Description	Presence	Type	Reserved Values
direction	The direction in which this value is measured. Inbound means the data transmission where the actor receives the data, and outbound means the data transmission where the actor transmits the data.	Mandatory	Word	Inbound Outbound
unit	The unit in which the value is represented. Bits/s means bits per seconds. Kbits/s means kilobits per seconds. One kilobit is 2^10 bits. Mbits/s means megabits per second. One megabit is 2^20 bits. Gbits/s means gigabits per second. One gigabit is 2^30 bits.	Mandatory	Word	GBits/s MBits/s KBits/s Bits/s
value	The rate value.	Mandatory	Number

 

3.1.3          Time Value

This type of object represents a time value.

 

Frame Ontology	time-value FIPA-MTS-QoS
Parameter	Description	Presence	Type	Reserved Values
direction	The direction in which this value is measured. Inbound means the data transmission where the actor receives the data, and outbound means the data transmission where the actor transmits the data.	Optional[6]	Word	Inbound Outbound
unit	The unit in which the value is represented. h means hours, m means minutes, s means seconds, and ms means milliseconds.	Mandatory	Word	h m s ms
value	The time value.	Mandatory	Number

 

3.1.4          Probability Value

This type of object represents a probability value.

 

Frame Ontology	probability-value FIPA-MTS-QoS
Parameter	Description	Presence	Type	Reserved Values
direction	The direction in which this value is measured. Inbound means the data transmission where the actor receives the data, and outbound means the data transmission where the actor transmits the data.	Optional	Word	Inbound Outbound
value	The probability value which obeys the following axiom: 0 ≤ value ≤ 1	Mandatory	Number

 

3.1.5          Change Constraint

This type of object represents constraints that limit quality of service notifications.

 

Frame Ontology	change-constraint FIPA-MTS-QoS
Parameter	Description	Presence	Type	Reserved Values
value	The description of the constraints.	Mandatory	Expression

 

3.1.6          Time Constraint

This type of object represents constraints that limit quality of service notifications.

 

Frame Ontology	time-constraint FIPA-MTS-QoS
Parameter	Description	Presence	Type	Reserved Values
type	The type of the constraint. If the type Every is used, then the expression becomes true after value and thereafter at intervals of value. If the type After is used, then the expression becomes true only after value.	Mandatory	Word	Every After
value