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 todays 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 todays 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, todays 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. Todays 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 entitys 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 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. 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 |
||