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 informative specifications for:
· Monitor Agent (MA) functionality, and
· Control Agent (CA) functionality.
In addition, three other FIPA specifications are related to nomadic application support: [FIPA00069], [FIPA00088] and [FIPA00094].
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 wire line 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.
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 Message Transport Protocol (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. 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 (QoS) can be split into several specific tasks:
1. Observing the QoS of MTPs and MTCs,
2. Measuring (if there are no other means to obtain the required information) the QoS 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 MA which carries out tasks 1 through 4, and,
· A 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 QoS 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.
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 wire line 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.
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-nas ontology. The fipa-nas ontology extends the fipa-qos ontology defined in [FIPA00094].
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 Transport Protocol Selection
This type of object represents a selection of transport protocol.
|
Frame Ontology |
transports fipa-nas |
|
||
|
Parameter |
Description |
Presence |
Type |
Reserved Values |
|
send |
A list of transport protocols supported for sending messages. |
Mandatory |
Sequence of transport-protocol[3] |
|
|
recv |
A list of transport protocols supported for receiving messages. |
Mandatory |
Sequence of transport-protocol |
|
3.1.2 Message Representation Description
This type of object represents an ACL message representation.
|
Frame Ontology |
msg-representation fipa-nas |
|
||
|
Parameter |
Description |
Presence |
Type |
Reserved Values |
|
name |
The name of the message representation. |
Mandatory |
word |
|
|
options |
A list of parameters for the message representation. |
Optional |
Set of property[4] |
|
3.1.3 Message Representation Selection
This type of object represents a selection of message representations.
|
Frame Ontology |
msg-encoding fipa-nas |
|
||
|
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-nas ontology.
The following terms are used to describe the functions of the fipa-nas 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 Transport Selection
|
Predicate |
transport-selection |
|
|
Ontology |
fipa-nas |
|
|
Supported by |
CA |
|
|
Description |
An agent specifies the transport protocols that it is willing to use. The predicate is true, when the values of the transports parameter contain the transport protocol descriptions that the agent is willing to use. Otherwise, the predicate is false |
|
|
Domain |
transports |
|
|
Arity |
1 |
|
3.2.2 Message Encoding Selection
|
Predicate |
msg-encoding-selection |
|
|
Ontology |
fipa-nas |
|
|
Supported by |
CA |
|
|
Description |
An agent specifies the message encoding choices that it is willing to use. The predicate is true, when the values of the msg-encoding parameter contain the message encoding choices that the agent is willing to use. Otherwise, the predicate is false |
|
|
Domain |
msg-encoding |
|
|
Arity |
1 |
|
3.2.3 Open Communication Channel
|
Function |
open-comm-channel |
|
|
Ontology |
fipa-nas |
|
|
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-nas |
|
|
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 c | |