FOUNDATION FOR INTELLIGENT PHYSICAL AGENTS

FIPA Nomadic Application Support Specification

Document title	FIPA Nomadic Application Support Specification
Document number	XC00014B	Document source	FIPA Nomadic Application Support
Document status	Experimental	Date of this status	2000/09/08
Supersedes	OC00062, OC00063, OC00065, OC00066
Contact	nomadic_app_supp@fipa.org
Change history
2000/03/07	Initial draft
2000/07/27	Recombined from OC00062, OC00063, OC00065, and OC00066. Changed envelope syntax to XML. Editorial changes.
2000/09/08	Added new (extended) scope, XML envelope updated, qos-information and qos-notification changed to predicates.

© 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 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 Scope. 1

2 General Analysis. 2

2.1 Overview. 2

2.2 Monitoring and Controlling Quality of Service. 3

2.3 Negotiation of Message Transport Requirements. 4

2.3.1 Negotiation About Message Transport Protocols. 4

2.3.2 Negotiation About Message Representation. 4

3 Nomadic Application Support Ontology. 5

3.1 Object Descriptions. 5

3.1.1 Service Description. 5

3.1.2 Quality of Service Description. 6

3.1.3 Rate Value. 7

3.1.4 Time Value. 7

3.1.5 Probability Value. 7

3.1.6 Change Constraint 8

3.1.7 Time Constraint 8

3.1.8 Communication Channel Description. 8

3.1.9 Transport Protocol Description. 9

3.1.10 Transport Protocol Selection. 9

3.1.11 Message Representation Description. 9

3.1.12 Message Representation Selection. 10

3.2 Function and Predicate Descriptions. 10

3.2.1 Request Monitoring Information. 10

3.2.2 Subscribe to Changes. 11

3.2.3 Open Communication Channel 11

3.2.4 Close Communication Channel 11

3.2.5 Activate a Message Transport Protocol 12

3.2.6 Deactivate a Message Transport Protocol 12

3.2.7 Select a Message Transport Protocol 12

3.3 Exceptions. 13

3.3.1 Not Understood Exception Propositions. 13

3.3.2 Refusal Exception Propositions. 13

3.3.3 Failure Exception Propositions. 14

4 Scenarios. 15

4.1 Registration with a DF. 15

4.2 Negotiating Message Transport Protocols. 16

4.3 Negotiating Message Representations. 20

4.4 Message Exchange Over a WAP Message Transport Protocol 21

4.4.1 Message Exchange Activation by an Agent in a Mobile Host 22

4.4.2 Message Exchange Termination to an Agent in a Mobile Host 24

5 Informative Annex A – Paramedic Scenario. 27

5.1 Overview. 27

5.2 Seamless Roaming. 29

5.2.1 Disconnection and Reconnection of an Message Transport Connection. 29

5.2.2 Example Negotiation of a Message Transport Protocol 33

5.2.3 Example Negotiation of a Message Representation. 36

6 References. 38

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 4.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 4.3, Negotiating Message Representation.

3 Nomadic Application Support Ontology

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 and FIPA-MTS-QoS ontologies.

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 Service Description

This type of object represents the description of each service registered with the DF.

Frame Ontology	service-description FIPA-Nomadic-Application
Parameter	Description	Presence	Type	Reserved Values
name	The name of the service.	Mandatory	String	fipa-mts-control fipa-mts-monitor
type	The type of the service.	Mandatory	String	fipa-ca fipa-ma
ontology	A list of ontologies supported by the service.	Optional	Set of String	FIPA-Nomadic-Application
protocol	A list of interaction protocols supported by the service.	Optional	Set of String
properties	A list of properties that discriminate the service.	Optional	Set of property

3.1.2 Quality of Service Description

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

Frame Ontologies	qos FIPA-Nomadic-Application 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 acknowledgement 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.	Optional	Word	Connected Disconnected Connecting

3.1.3 Rate Value

This type of object represents a data transfer value.

Frame Ontologies	rate-value FIPA-Nomadic-Application FIPA-MTS-QoS
Parameter	Description	Presence	Type	Reserved Values
direction	The direction in which this value is measured.	Mandatory	Word	Inbound Outbound
unit	The unit in which the value is represented.	Mandatory	Word	GBits/s MBits/s KBits/s Bits/s
value	The rate value.	Mandatory	Number

3.1.4 Time Value

This type of object represents a time value.

Frame Ontologies	time-value FIPA-Nomadic-Application FIPA-MTS-QoS
Parameter	Description	Presence	Type	Reserved Values
direction	The direction in which this value is measured.	Optional[6]	Word	Inbound Outbound
unit	The unit in which the value is represented.	Mandatory	Word	h m s ms
value	The time value.	Mandatory	Number

3.1.5 Probability Value

This type of object represents a probability value.

Frame Ontologies	probability-value FIPA-Nomadic-Application FIPA-MTS-QoS
Parameter	Description	Presence	Type	Reserved Values
direction	The direction in which this value is measured.	Optional	Word	Inbound Outbound
value	The probability value which obeys the following axiom: 0 ≤ value ≤ 1	Mandatory	Number

3.1.6 Change Constraint

This type of object represents constraints that limit quality of service notifications (see section 3.2.2, Subscribe to Changes).

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

3.1.7 Time Constraint

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

Frame Ontologies	time-constraint FIPA-Nomadic-Application 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	The time value.	Mandatory	time-value

3.1.8 Communication Channel Description

This type of object represents a communication channel.

Frame Ontologies	comm-channel FIPA-Nomadic-Application FIPA-Communication-Management
Parameter	Description	Presence[7]	Type	Reserved Values
name	The logical name of the communication channel.	Optional	Word
target-addr	The target transport address of the communication channel. This may also be the address of a gateway ACC.	Optional	URL
options	A list of optional parameters for the communication channel.	Optional	Set of property (see [FIPA00023])

3.1.9 Transport Protocol Description

This type of object represents a transport protocol.

Frame Ontologies	transport-protocol FIPA-Nomadic-Application FIPA-Communication-Management
Parameter	Description	Presence	Type	Reserved Values
name	The logical name of the transport protocol.	Mandatory	Word
gw-addr	The transport address of the gateway ACC.	Optional	URL
dest-addr	The transport address of the ultimate destination. If this address is present, but gw-addr is not, then the Control Agent may select the most appropriate gateway transport address to use.	Optional	URL
options	A list of optional parameters for the transport protocol.	Optional	Set of property

3.1.10 Transport Protocol Selection

This type of object represents a selection of transport protocol.

Frame Ontologies	transports FIPA-Nomadic-Application FIPA-Communication-Management
Parameter	Description	Presence	Type	Reserved Values
send	A list of transport protocols supported for sending messages.	Mandatory	Sequence of transport-protocol
recv	A list of transport protocols supported for receiving messages.	Mandatory	Sequence of transport-protocol

3.1.11 Message Representation Description

This type of object represents an ACL message representation.

Frame Ontologies	msg-representation FIPA-Nomadic-Application FIPA-Message-Representation
Parameter	Description	Presence	Type	Reserved Values
name	The name of the message representation.	Mandatory	Word	See [FIPA00068]
options	A list of parameters for the message representation.	Optional	Set of property

3.1.12 Message Representation Selection

This type of object represents a selection of message representations.

Frame Ontologies	msg-rep-selection FIPA-Nomadic-Application FIPA-Message-Representation
Parameter	Description	Presence	Type	Reserved Values
send	A list of message representations supported for sending messages.	Mandatory	Sequence of msg-representation
recv	A list of message representations supported for receiving messages.	Mandatory	Sequence of msg-representation

3.2 Function and Predicate Descriptions

The following tables define usage and semantics of the functions and the predicates that are part of the FIPA-Nomadic-Application ontology.

The following terms are used to describe the functions of the FIPA-Nomadic-Application domain:

· Function. This is the symbol that identifies the function in the ontology.

· Predicate. This is the symbol that identifies the predicate in the ontology.

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

· Supported by. This is the type of agent that supports this function or predicate.

· Description. This is a natural language description of the semantics of the function or the predicate.

· Domain. This indicates the domain over which the function predicate is defined. The arguments passed to the function or predicate must belong to the set identified by the domain.

· Range. This indicates the range to which the function maps the symbols of the domain. The result of the function is a symbol belonging to the set identified by the range.

· Arity. This indicates the number of arguments that a function or a predicate takes. If a function or a predicate can take an arbitrary number of arguments, then its arity is undefined.

3.2.1 Request Monitoring Information

Predicate	qos-information
Ontology	FIPA-Nomadic-Application
Supported by	MA
Description	An agent asks for quality of service information from an MA using the FIPA-Query interaction protocol (see [FIPA00027]). The agent may specify either a communication channel or transport protocol to request quality of service information from.
Domain	comm-channel / transport-protocol, qos
Arity	2

3.2.2 Subscribe to Changes

Predicate	qos-notification
Ontology	FIPA-Nomadic-Application
Supported by	MA
Description	An agent subscribes to notifications about changes to the quality of service from an MA using the FIPA-Subscribe interaction protocol (see [FIPA00035]).
Domain	comm-channel, qos, change-constraints / time-constraints
Arity	3

3.2.3 Open Communication Channel

Function	open-comm-channel
Ontology	FIPA-Nomadic-Application
Supported by	CA
Description	An agent can request that a CA open a communication channel. The communication channel description should contain enough information for a CA to be able to choose the right communication channel, that is, either the :name parameter or the :target-addr parameter must be present. The agent may also supply additional communication channel information by using the :options parameter.
Domain	comm-channel
Range	The execution of this function results in a change of the state, but it has no explicit result. Therefore there is no range set.
Arity	1

3.2.4 Close Communication Channel

Function	close-comm-channel
Ontology	FIPA-Nomadic-Application
Supported by	CA
Description	An agent can request that a CA close a communication channel. The communication channel description should contain enough information for a CA to be able to choose the right communication channel, that is, either the :name parameter or the :target-addr parameter must be present.
Domain	comm-channel
Range	The execution of this function results in a change of the state, but it has no explicit result. Therefore there is no range set.
Arity	1

3.2.5 Activate a Message Transport Protocol

Function	activate
Ontology	FIPA-Nomadic-Application
Supported by	CA
Description	An agent can request that a CA activate a Message Transport Protocol (MTP). The transport protocol description should contain enough information to allow the CA to identify the correct transport protocol. Additionally, the agent may supply address information to where the transport protocol connection should be opened. It is possible to give the address of the gateway and/or the address of the destination AP.
Domain	Sequence of transport-protocol
Range	The execution of this function results in a change of the state, but it has no explicit result. Therefore there is no range set.
Arity	1

3.2.6 Deactivate a Message Transport Protocol

Function	deactivate
Ontology	FIPA-Nomadic-Application
Supported by	CA
Description	An agent can request that a CA deactivate an MTP.
Domain	transport-protocol
Range	The execution of this function results in a change of the state, but it has no explicit result. Therefore there is no range set.
Arity	1

3.2.7 Select a Message Transport Protocol

Function	use
Ontology	FIPA-Nomadic-Application
Supported by	CA