FIPA-compliant agents for real-time control of Intelligent Network traffic

Ž .Computer Networks 31 1999 2017–2036www.elsevier.comrlocatercomnet

FIPA-compliant agents for real-time control of IntelligentNetwork traffic

Brendan Jennings a,), Rob Brennan a, Rune Gustavsson b, Robert Feldt b,Jeremy Pitt c, Konstantinos Prouskas c, Joachim Quantz d

a Teltec Ireland, Dublin City UniÕersity, Dublin, Irelandb UniÕersity of KarlskronarRonneby, Ronneby, Sweden

c Imperial College of Science, Technology and Medicine, London, UKd IKV qq, Berlin, Germany

Abstract

Autonomy, adaptability, scalability, and flexible communications are all attributes of agents and multi-agent systemswhich suggest that they may offer timely solutions for dealing with the growing complexity of the tasks of traffic control andresource management in telecommunications networks. However, if agent-based solutions to network management problemsare to be successful then it will be important that heterogeneous agents and agent platforms inter-operate in accordance withinternationally accepted standards. Although standards of this nature are being developed, they are not tailored specifically tothe needs of the telecommunications domain, with the result that important issues, such as support for the operation of agentsystems in real-time constrained environments, do not seem to be adequately addressed. We present two agent-based systemsfor control of traffic load and resource allocation in Intelligent Networks. One of these strategies is based on the concepts of‘Market-based Control’, the other on the concepts of ‘Ant Colony Optimisation’. Using the market-based strategy as anexample we show that enhancements to existing FIPA specifications would be required to implement these strategies inorder to satisfy their real-time operation constraints. We also suggest a number of potential enhancements to FIPAspecifications that would alleviate some of the identified problems. q 1999 Elsevier Science B.V. All rights reserved.

Keywords: Agent technology; Intelligent network; Load control; Market-based control; Ant colony optimisation; FIPA; ACL; Real-timeenhancement

1. Introduction

Two distinguishing characteristics of contempo-rary telecommunications are the increased complex-ity of the marketplace and of the underlying technol-ogy. The industry is being ‘pulled’ by market factorssuch as deregulation, federation of multiple service

) Corresponding author. Tel.: q353-1-704-5816; Fax: q353-1-704-5092; E-mail: [email protected]

providers, and the trend towards service-orientedoperations; and being ‘pushed’ by technological ad-vances allowing service profiling from alternativenetwork access points, integrated multi-servicebroadband networks, and interoperable telecommuni-cations and computer network infrastructures. Thesefactors mean that the complexity and level of con-nectivity of networks is continually growing, in orderto support the range and volume of informationproduced by users. Increases in network complexity

1389-1286r99r$ - see front matter q 1999 Elsevier Science B.V. All rights reserved.Ž .PII: S1389-1286 99 00077-8

( )B. Jennings et al.rComputer Networks 31 1999 2017–20362018

and information volumes suggests that approaches tothe management of telecommunications systems, ser-vices and networks will need to be more responsive,adaptive, proactive, and less centralised. As these areproperties of agents and multi-agent systems manyin the telecommunications research community haverecognised that agent-based technology appears tooffer a timely solution to the growing problem ofdesigning efficient and flexible network managementstrategies.

An important prerequisite for the introduction ofagent-based systems into telecommunications net-works is the availability of internationally agreedagent platform interoperability standards. Work inthis direction is taking place within the Foundation

Ž . w xfor Intelligent Physical Agents FIPA 7 and withinŽ . w xthe Object Management Group OMG 18 . The

OMG have produced the Mobile Agent System In-Ž .teroperability Facility MASIF , which focuses on

Ž .mobile agent object technology, in particular al-lowing for the transfer of an agents code and statebetween heterogeneous agent platforms. The FIPA’97and FIPA’98 specifications, on the other hand, deal

Ž .with interoperability between more or less staticagent classes that rely on agent ‘intelligence’ andagent co-operation based on high-level speech actcommunication. This standard is thus based on re-

( )search on intelligent deliberatiÕe agents that hasemerged from the Distributed Artificial Intelligencecommunity.

Existing MASIF and FIPA standards have beendeveloped with a wide range of application domainsin mind and thus important non-functional require-ments of agent-based telecommunications manage-ment systems may not be adequately addressed.These requirements can relate to the system’s re-liability, scalability, security, ability to meet per-formance targets and ability to satisfy real-time

w xconstraints. The ACTS–MARINER project 15 isinvestigating how FIPA standards can be enhancedin order to provide the support necessary to meet thereal-time and performance requirements of telecom-munications applications. The project is developing aFIPA-compliant agent system for Intelligent Net-

Ž . Žwork IN load control a problem particularly suited.to agent technology-based solutions in order to iden-

tify areas in which FIPA specifications could bebeneficially enhanced.

In this paper we present two agent-based IN loadcontrol strategies, one based on the concepts of

w x‘Market-Based Control’ 5 , the other on the con-w xcepts of ‘Ant Colony Optimisation’ 6 and iden-

tify some of the relevant real-time and performanceconstraints placed on the agents that implementthem. We show that compliance to existing FIPAspecifications would make it difficult to satisfy theserequirements and suggest a number of potential en-hancements that would alleviate the identified short-comings. It is to be emphasised that we do notcontend that existing FIPA standards are necessarily‘incorrect’, rather that because they were developed

Žto cover the needs of specific applications none of.which include real-time constraints there is a need

for enhancements when applying them to the type ofapplications discussed here.

The outline of the paper is as follows: Section 2provides an introduction to the area of IN loadcontrol and provides arguments in favour of agent-based strategies; Section 3 introduces ‘Co-operativeMarket’ and ‘Ant-Based’ IN load control strategies;Section 4 is implementation-oriented in nature, out-lining how the co-operative market strategy can berealised as a FIPA-compliant multi-agent system;Section 5 reports on a number of deficiencies in theFIPA’97 specifications identified when applyingthem to the MARINER load control strategies andprovides pointers towards suitable enhancements toFIPA standards; finally Section 6 draws a number ofconclusions and outlines future work topics.

2. Intelligent Network load control

The Intelligent Network architecture was devel-oped as a means to introduce, control and manageservices both rapidly, cost effectively and in a man-ner not dependent on equipmentrsoftware from par-ticular equipment manufacturers. An IN networkconsists of four node types: Service Switching PointsŽ . Ž .SSP , Service Control Points SCP , Service Data

Ž . Ž .Points SDP and Intelligent Peripherals IP . Thesenode types typically communicate with each other

Ž .via a Signalling System No. 7 SS.7 network. SSPsfacilitate end user access to services by means oftrigger points for detection of service access codes.SCPs form the core of the architecture, they receiveservice requests from SSPs and execute the relevant

( )B. Jennings et al.rComputer Networks 31 1999 2017–2036 2019

service logic. SCPs are assisted by SDPs, whichstore servicercustomer related data, and by IPs,which provide services for interaction with end-usersŽ .e.g., automated announcements or data collection .A more complete description of the IN architecture

w xcan be found in 9,10 .Intelligent Network overloads occur when the load

Žoffered to one or more network resources e.g., SCP.processors exceeds the resource’s maximum capac-

ity. Network operators endeavour to dimension net-work resources to ensure that overloads are unlikelyto occur, however for INs supporting a varying set ofservices with associated usage demands this task isvery difficult. Because of this networks are becom-ing more susceptible to overloads, which result incustomer dissatisfaction and, where service requestsare abandoned, loss in revenue for the network oper-ator. In current INs most situations of this natureresult from very large increases in the volume oftraffic arriving at an SCP as a result of media-stimu-

w xlated mass call-in events 3 , however it has beenobserved that the frequency and severity of generaloverload occurrences is on the increase. In this con-text the presence of efficient and flexible load con-trol mechanisms, which take measures to avoid theonset of harmful overloads in the network is becom-ing increasingly important.

2.1. Node-based Intelligent Network load controlmechanisms

Because of the central role played by the SCP theoverall goal of most IN load control mechanisms hasbeen to protect SCP processors from overload,thereby providing customers with high service avail-ability and acceptable network response times, evenduring periods of high network loading. In additionto this goal load control mechanisms have beendesigned to be:Ø Efficient – keeping SCP utilisation as high as

possible at all times;Ø Scalable – suited to all networks, irrespective of

their size and topology;Ø ResponsiÕe – reacting quickly to changes in the

network or offered traffic levels;Ø Fair – distributing system capacity among both

the network users and service providers in amanner deemed ‘fair’ by the network operator;

Ø Stable – avoiding fluctuations or oscillations inresources utilisation;

Ø Simple – in terms of ease of implementation.The majority of publicly documented IN load

control mechanisms are ‘node-based’ in nature, fo-cusing on protecting individual nodes in the networkŽ .typically SCPs from overload. We classify node-based mechanisms as being of two types: ‘co-oper-ative’ or ‘non-co-operative’. Co-operative methodsinvolve SSPs and SCPs communicating with eachother to control traffic, whereas in non-co-operativemechanisms SSPs control traffic-based on their ownmeasurements only.

In co-operative node-based strategies, an overloaddetection algorithm is located at the SCP and worksin conjunction with a service request throttlingmechanism located in the SSP. When the SCP over-load is detected, a control message indicating theseverity of the overload is sent, via the SS.7 net-work, to the SSP, where it is interpreted and anappropriately severe throttle is put in place to restrictincoming IN service requests. Types of throttling

( )mechanisms include Automatic Call Gapping ACG ,Percent Thinning, and The Leaky Bucket. The widely

Ždeployed ACG mechanism which is supported byw x.IN standards 11 operates by accepting no more

than N class i service requests every T seconds,where the values of N, T and i are extrapolated fromthe contents of ACG messages sent from SCP toSSP.

In non-co-operative load control mechanisms, bothoverload detection and throttling of calls takes placeat SSPs. The SCP sends no notification of overloadto SSPs. At SSPs, an algorithm is in place thatmonitors the response time of the SCP to requestsfrom that SSP. If the mean response delay for servicerequests becomes excessive, overload is deemed tohave occurred and incoming calls are throttled. Themost widely used algorithms are based on WindowControl, in which only W service sessions may be inprogress at any one time, the value of W beingbased on measurements of service request responsetimes.

Much research has focused on comparisons be-tween various control mechanisms. For example ithas been shown that ACG generally reacts faster

Žthan Window to the onset of overload because it isinvoked by direct rather than indirect measurements


. w xof resource load 19 , whereas Window performsbetter in the presence of SS.7 network overloadsw x13 . However, we contend that node-based mecha-nisms in general cannot alone guarantee that desiredquality of service levels are consistently achieved.The following observations support this viewpoint:Ø Most currently deployed node-based mechanisms

were designed for standard telephony traffic pat-terns. Present and future INs support a largenumber of heterogeneous services, each exhibit-ing differing traffic characteristics that cannot beeffectively controlled using node-based tech-niques;

Ø Existing node-based overload protection mecha-nisms serve to protect individual nodes only andmay cause the propagation of traffic congestion,resulting in adverse effects on the service comple-tion rates of the network as a whole;

Ø Typically node-based mechanisms do not interacteffectively with the protection mechanisms thatare incorporated into the signalling networks thatcarry information between the nodes in a net-work. This lack of co-ordination means that oftennode-based mechanisms are at best ineffectualand can even serve to exasperate the overloadsituation;

Ø Node-based controls typically focus on SCP pro-tection only; however, a network operator maywish that network profit is maximised, or maywish to ensure that particular service types aregiven higher priority in times of overload;

Ø Telecommunications equipment manufacturersimplement node-based mechanisms on a propri-etary basis. This can lead to difficulties in effec-tively controlling traffic in INs that contain aheterogeneous mix of equipment types.

2.2. ‘Network-based’ IN load control

The inherent drawbacks of node-based controlslisted above point towards the need for controlswhich deal with high offered load levels in a mannersuch that the entire network benefits. The operationof such controls may result in certain resources inthe network operating at a level that is from the localperspective less than optimal, however a more global

Žmeasure of network performance such as number of

.successful sessions or generated revenue will bemaximised. A description of a network-based INload control mechanism, consisting of a load predic-tor described as a state machine and a throttlingmechanism that applies Bayesian decision theory,

w xcan be found in 1 .While flexible and adaptable network-based load

control mechanisms could certainly be implementedusing standard software engineering techniques, weargue that there are many advantages to be gainedthrough the adoption of an agent-based approach:Ø Methodology: the agent paradigm encourages a

knowledgerinformation centred approach to ap-plication development, thus it may provide a use-ful methodology for the development of controlmechanisms that require manipulation of largeamounts of data collected throughout a network.

Ø Agent Communication Languages: much work inthe agent research community has focused ondevelopment of advanced communications lan-guages that, for example, allow agents to negoti-ate in advance the semantics of future communi-cations. This degree of flexibility is not present intraditional communications protocols and wouldbe of use in realising mechanisms that adapt todynamic network environments where, for exam-ple, traffic patterns change due to introduction orwithdrawal of services;

Ø AdaptiÕity: agents may have adaptive behaviourallowing them to learn about the normal state ofthe network and better judge their choice of fu-ture actions. A substantial body of work relatingto learning behaviour in the context of agentsystems exists and could be leveraged to incorpo-rate learning behaviour into a load control mecha-nism;

Ø Openness: the agent approach is very open, inthat individual agents may exchange data andapply it in different ways to achieve a commongoal. This means that equipment manufacturerscould develop load control agents tailored to theirown equipment, but which could still effectivelycommunicate with agents residing in other equip-ment types;

Ø Scalability: the agent approach allows for in-creased scalability to larger networks. For exam-ple an agent associated with a recently introducedpiece of equipment can easily incorporate itself


into the agent community and learn from theother agents the range of parameters that it shoulduse for its load control algorithms;

Ø Robustness: agents typically communicate asyn-chronously with each other and thus are not de-pendent on prompt delivery of inter-agent mes-sages. The ability to act even during interrupted

Žcommunications e.g., due to overload or network.failures is a desirable attribute of a load control

mechanism.In summary it can be said that agent technology

provides a knowledge-centred methodology forbuilding flexible, adaptable, open and robust solu-tions for inherently distributed network control prob-lems.

3. MARINER agent-based load control strategies

Load Control in Intelligent Networks can beviewed as a distributed resource allocation problem:

Ž .resources particularly SCP processors must be allo-cated in an optimal way to the arriving user servicerequests. We identify three classes of agents thatcarry out the general tasks necessary to allocate INresources in an optimal manner:1. QUANTIFIER agents, which monitor and predict the

Žloadrperformance of SCP processors and possi-.bly other IN resources and report this informa-

tion to other agents;2. DISTRIBUTOR agents, which maintain an overview

of the load and resource status in the entirenetwork and may play a controlling or supervi-sory role in resource allocation;

3. ALLOCATOR agents, which are associated withSSPs. They form a view of the load situation inthe network and the possibility of resource over-

Ž .load, based on their own predictive algorithm sand information received from other agents. Ifthey perceive that there is danger of overload ofresources they throttle service requests on a prior-ity basis.In the remainder of this section we present two

separate strategies which a community of ALLOCA-ŽTORS, QUANTIFIERS and DISTRIBUTORS and possibly.mobile ‘ant’ agents – see Section 3.2 could use to

control the allocation of the processing capacity of a

number of SCPs between requests for a number ofIN service types. A simplified network scenario,

Žcontaining M SSPs and N SCPs each supporting.all service types was used as a fundament for the

development of these strategies. It is illustrated inFig. 1.

3.1. Co-operatiÕe market strategy

The strategy that we will describe in this sectionis an application of ‘computational markets’ – adistributed resource allocation paradigm building oneconomic utility theory in electronic markets. Mar-ket-based control has been successfully applied to

w xproblems such as ATM bandwidth allocation 8 andw xpower load management 24 ; an overview of this

w xexpanding research area can be found in 5 .Computational Markets as applied to resource

allocation problems are generally implementations ofŽGeneral Equilibrium Theory developed in the field

.of microeconomics , whereby agents in the marketset prices and create bids for resources, based ondemand and supply functions. Once equilibrium hasbeen computed from the bids of all the agents, theresources are allocated in accordance with the bidsand the equilibrium prices. The search for the marketequilibrium can be implemented so that the customerandror producer submit bids to an auctioneer. Fromthese bids, the auctioneer updates its information andrequests new bids in an iterative fashion. Once themarket equilibrium has been found, the re-allocationof goods is performed in accordance with the bidsand market prices.

Fig. 1. Simplified IN scenario.


In our strategy, load control is carried out bymeans of tokens, which are ‘sold’ by MB-QUANTI-

ŽFIER agents where the MB-prefix indicates that the.agent implements part of a market-based strategy of

Ž .‘providers’ SCP and ‘bought’ by MB-ALLOCATOR

Ž .agents of ‘customers’ SSP . The amount of tokenssold by an SCP controls the load offered to it, andthe amount of tokens bought by an SSP determineshow many IN service requests it can accept. ‘Trad-

Ž .ing’ of tokens in an ‘auction’ is carried out suchthat the common good is maximised, hence the termco-operatiÕe market strategy.

All SSPs contain a number of pools of tokens,one for each SCP and service class pairing. Eachtime an SSP feeds an SCP with a service request onetoken is removed from the relevant pool. An emptypool indicates that the associated SCP cannot acceptmore requests of that type from the SSP. Tokens areperiodically assigned to pools by an MB-DISTRIBU-TOR, which uses an auction algorithm to calculatetoken allocations. Auctions are centrally imple-

Žmented by an MB-DISTRIBUTOR using ‘bids’ re-.ceived in the form of messages every interval from

all the MB-ALLOCATORS and MB-QUANTIFIERS in thenetwork.

MB-QUANTIFIER bids consist of the unclaimedprocessing capability for the coming interval and theprocessing requirements for each service class. In asimilar manner MB-ALLOCATOR bids consist of thenumber of expected IN service requests over the nextinterval for each service class respectively. Thesevalues are simply set to the number that arrived inthe previous interval – this is assumed to be areasonably accurate estimate.

The objective of the auction process is to max-imise expected network profit over the next interval.To do this, it maximises the increase in expectedmarginal utility, measured as marginal gain overcost, for every token issued. The expected marginalgain associated with allocating an additional token toan MB-ALLOCATOR is defined as the profit associatedwith consuming it times the probability that it will beconsumed over the auction interval. The expectedmarginal cost associated with issuing a token froman MB-QUANTIFIER is defined as the ratio betweenthe processing time consumed and the remainingprocessing time. Based on these values the MB-DIS-TRIBUTOR implements a maximisation algorithm that

is iterated to allocate all the available tokens. Tokenswill typically be allocated to MB-ALLOCATORS with

Ž‘higher’ bids i.e., those which expect greater num-bers of requests for service sessions that result in

.high profits in preference to those with ‘lower’ bids.The operation of the auction algorithm where

there is only one service class supported by theŽ .network, is illustrated by Fig. 2. In step 1 MB-

QUANTIFIERS and MB-ALLOCATORS submit their bidsto the MB-DISTRIBUTOR, which then runs the auction

Ž .process – step 2 . In the figure dark circles repre-sent tokens, whereas light circles represent tokenrequests, the auction algorithm assigns tokens totoken requests in the manner described above. Oncethe auction is complete, the values of token assign-ments are reported to the MB-ALLOCATORS, whichuse them to admit service requests in the next timeperiod.

The net effect of the auction process is that tokensare allocated in a manner that will serve to balancethe arriving traffic load across all SCPs, subject tomaximising the overall network profit. A completespecification of the co-operative market strategy,enhanced to support multiple distributed auctions,and the results of a quantitative study of its perfor-

w xmance, can be found in 2 .

3.2. Ant-based strategy

The Load Control strategy that will be proposedin this section takes its inspiration from previous

Fig. 2. Co-operative Market Strategy.


studies on Ant Colony Optimisation, which is theapplication of approaches based on the behaviour ofreal ant colonies to optimisation problems. IN loadcontrol may be viewed as an optimisation problem –the utilisation of network resources should be opti-mised with respect to some measure such as qualityof service or generated revenue.

Ant Colony Optimisation has been applied tow xproblems such as routing in circuit- 22 and packet-

w xswitched 6 networks. These studies have demon-strated that ant-based distributed control can havemany advantages, for example: high performance interms of maximising call throughput; scalability; andadaptability to different network topologies, trafficpatterns and transient overloads. Results such asthese make it attractive to apply a similar approachfor IN Load Control, where optimal utilisation ofavailable resources under varying traffic conditionsis a key goal.

3.2.1. Background informationIndividual ants are very unsophisticated insects

from a behavioural point of view; however, coloniesof ants, acting as a collective, are capable of per-forming relatively complex tasks, such as buildingand protecting their nest, forming bridges, colonyemigration and finding the shortest routes from thenest to a food source. Such behaviour arises throughindirect communication between the ants, affectedthrough modifications induced in the environment –a process called ‘stigmergy’. An example of stig-mergy is the means foraging ants use to quickly findthe shortest path to a food source: individual antsfollowing a particular path will deposit a type ofhighly volatile hormone, called a ‘pheromone’, giv-ing rise to a ‘pheromone trail’ for that path. Ingeneral, ants faced with a decision between alterna-tive paths will follow the path for which thepheromone trail is strongest. However, the shortestpath will tend to acquire stronger trails more rapidlyŽsince the ant’s round trip time will be shorter and

.thus more pheromone will be deposited , therebycausing more ants to follow it. This results in posi-tive feedback, ensuring that the shortest path isquickly identified and utilised by the majority of theforaging ants.

The trail laying behaviour described above can bequite straightforwardly applied to routing in telecom-

munications networks by replacing the routing tablesin network nodes by tables of probabilities represent-ing the ‘pheromone strength’ for onward routes fromthat node. Mobile ‘Ant’ agents may then travel

Žbetween various destinations in the network selected.on the basis of pheromone values and use informa-

Ž .tion they collect e.g., network traversal delay toupdate these pheromone tables. In order to route acall or data packet the pheromone table can then beconsulted for its destination and the route with thecurrent highest pheromone value selected.

3.2.2. Strategy descriptionWe will now describe the main points of the

operation of an Ant-based IN Load Control strategy.The operation of the strategy is illustrated by Fig. 3:

ŽØ At intervals of length T , a mobile agent anAB-ANT, where AB- indicates the Ant-based

.strategy is generated for every service type atevery one of the SSPs in the network and sent toa selected SCP;

Ø Each SSP maintains pheromone tables for eachservice type, which contain entries for all theSCPs in the network. These entries are the nor-malised probabilities, P of choosing SCP as thei i

destination for an AB-ANT;Ø The destination SCP of an AB-ANT is selected

using the information in the pheromone tablefollowing one of two schemes: either the ‘normalscheme’ or the ‘exploration scheme’. The schemeused is selected at random, but with the probabil-ity of using the exploration scheme being muchless than that for the normal scheme;

Fig. 3. Ant-Based Strategy.


Ø In the normal scheme the SCP is selected ran-domly, the probability of picking SCP being thei

probability P indicated in the pheromone tableiŽthis is analogous to the trail selection behaviour

.of real ants ;Ø In the exploration scheme the SCP is also se-

lected randomly, however the probabilities of se-lecting all the SCPs are equal. The purpose of theexploration scheme is to introduce an element ofnoise into the system so that more performantSCPs can be found – this is analogous to a smallnumber of real ants which do not follow the‘recommended’ trail, but which, as a result, mayfind even better trails;

Ø AB-ANTS travel to the designated SCP, wherethey interact with the local AB-QUANTIFIER agentand then return to their originating SSP. In doingso they keep track of the time they have spenttraversing the network;

Ø AB-ANTS arriving at the SCP will request infor-mation from the AB-QUANTIFIER on the currentlyexpected average processing times for the servicetype of interest. Processing times reported will bethe processing time for the initial message of theservice session, and the sum of the processingtimes for all other messages. Note that the separa-tion between the processing times for the initialand subsequent messages is made to highlight theimportance of the time spent processing the initialmessage, at which time the service user will notyet have received any response from the network.Reported processing times will include those in-curred in accessing information from databases,which may be held in SDPs in other parts of thenetwork;

Ø Upon return to the SSP the AB-ANT passes itsgathered information to the AB-ALLOCATOR whichthen updates the pheromone table entries for itsservice type, using a formula of the form

P qD piP si 1qD p

where i indicates the visited SCP

Pj w xP s , jg 1, N , j/ ij 1qD p

with

a b c dD ps q q q qe

t t t t1 2 3 4

where a, b, c, d, and e are constants; t is time1

elapsed travelling SSP™SCP; t is expected2

mean SCP processing for initial message; t is3

expected mean SCP processing time for subse-quent messages; t is time elapsed travelling SCP4

™SSP.The values of a, b, c and d represent the relativeimportance the AB-ALLOCATOR gives to each ofthe four measurements;

Ø Requests for a service are routed to the SCP thathas the current highest probability value in theservice’s pheromone table. Fig. 3 illustrates thatin normal load conditions the operation of thestrategy will mean that SCPs with closer proxim-ity to a source are more likely to be chosen as thedestination for service requests – this is becausethe delays AB-ANTS experience in travellingtorfrom them is less than for other SCPs.

4. FIPA-compliant multi-agent system for strat-egy realisation

In order to give a background to the discussion ofshortcomings of and suggested enhancements to theFIPA specifications that will be presented in Section5, this section will outline how the competitivemarket strategy discussed above could be imple-mented in compliance with FIPA’97 specifications.The choice of the competitive market over the antstrategy was motivated by the fact that it places morereal-time constraints on the operation of the agents.Not only do they need to synchronise on a global

Žview of time as is also the case with the Ant-based.strategy , but there are time constraints associated

with the duration of the auction processes. The auc-tion process must complete a sufficient length oftime before the start of the next interval to allowtoken allocations to be communicated to all theMB-ALLOCATOR agents participating in the auction.The competitive market strategy also requires moresophisticated inter-agent communication in order tofacilitate registration with auctions and negotiationon the data format for bids and token allocations.


The most important task when designing anagent-based application to be compliant with theFIPA’97 is to specify the required inter-agent com-munications in terms of required ACL performatives,ACL message parameters, message protocols andmessage content. Each of these aspects will be cov-ered in this section.

4.1. Messages specifications

This section analyses the messages exchangedbetween an MB-QUANTIFIER or MB-ALLOCATOR andan MB-DISTRIBUTOR, and their specification as FIPAACL messages. There are three aspects to this ex-change that are identified and defined:1. At the message layer, the FIPA ACL performa-

tives that are exchanged; and also2. The parameters for each message, including the

real-time requirements and constraints;3. At the communication layer, the content of each

message.Thus the first two aspects are concerned with the

‘logic’ of communication, and the real-time con-straints on that logic. The third aspect is concernedwith actual domain-specific content of each commu-nication, which itself may have real-time informa-tion. The first two aspects are addressed in Section4.1.1, where we first define two Message Sequence

Ž .Charts MSCs for the interactions between MB-QUANTIFIERS or MB-ALLOCATORS and an MB-DIS-TRIBUTOR, namely for registration and auctioning. InSection 4.1.2 we specify the contents of the mes-

Ž .sages by using Extensible Mark-up Language XMLw x23 for the MARINER content language.

The MSC for an MB-QUANTIFIER or an MB-AL-LOCATOR registering to participate in an auction man-aged by a particular MB-DISTRIBUTOR is illustrated inFig. 4. We note the following assumptions:1. The MB-QUANTIFIER, MB-DISTRIBUTOR, and

MB-ALLOCATOR are synchronised on a commonclock. For the rolling auction managed by theMB-DISTRIBUTOR, the MB-DISTRIBUTOR is the time

Ž .server in Cristian’s Algorithm cf., Section 4.2 ;2. The MB-QUANTIFIER, MB-DISTRIBUTOR and MB-

ALLOCATOR communicate about timeslots, whichŽ . Ž .are 1 of actual duration, 2 the duration is

determined by the MB-DISTRIBUTOR but need not

Fig. 4. Registration MSC.

Ž .be fixed, 3 the timeslots are identified by aŽ .unique integer; and 4 the timeslots themselves

are superimposed on a physical timeline;

4.1.1. MSC for registration and auctionThe MSC for registration is illustrated in Fig. 4.

The general idea is that a MB-QUANTIFIER or MB-ALLOCATOR registers with a MB-DISTRIBUTOR in or-der to respectively supply or demand ‘IN servicerequest processing capacity’, i.e., the SCP computingresources required to satisfy a request for a certaintype of IN service. The initial registration requestspecifies basic communication requirements such asname, channel, addressrport etc. of the originatingMB-QUANTIFIERrALLOCATOR. Then the MB-QUANTI-FIERrALLOCATOR and MB-DISTRIBUTOR must con-verge on domain and content-specific information,specifically:Ø the data format – which IN services are bidded

for and their representations;


Ø the time format – for example, the name, durationand actual start time of the timeslot for the firstauction in which the MB-QUANTIFIERrALLOC-ATOR can participate;

Ø the current time – for clock synchronisation.After successful registration the MB-QUANTIFIER orMB-ALLOCATOR can make an ‘offer’ or a ‘bid’ in the

Žauction that takes place in the agreed timeslot and.subsequent auctions in successive timeslots .

The MSC for a MARINER auction, taking placein time slot T , is illustrated in Fig. 5. Note that theauction lasts only a fraction of the timeslot. Duringthis time, the MB-DISTRIBUTOR must compute thetoken allocation to each MB-ALLOCATOR, anddespatch this to each MB-ALLOCATOR in time for itto pass the tokens onto its associated SSP. TheMB-DISTRIBUTOR will seek to minimise the durationof the auction process itself, while ensuring that theprocess is completed. The shorter the auction pro-cess, then the later the bids can be submitted. The

Fig. 5. Auction MSC.

later a bid is submitted, the more likely it is to havebeen recently updated and therefore a more accurateestimate of resource requirements. Furthermore, ifthe MB-DISTRIBUTOR has received all bids in timeand can complete the auction process, we can be surethe token allocation is optimal.

The ACL messages exchanged in Fig. 5 are asfollows:Ø MB_AuctionServiceRequest is a ‘bid’ from

an MB-ALLOCATOR containing expected arrivalrates as a compressed representation of their util-ity function;

Ø MB_AuctionServiceOffer is an ‘offer’ froman MB-QUANTIFIER, containing processing times

Ž .per service class available offered with the cur-rent configuration and software versions. There isalso, as one single item, the complete processingtime available with the current processor, operat-ing system etc.;

Ø MB_AuctionTokenDistribution is a‘grant’ from the MB-DISTRIBUTOR to the MB-AL-LOCATOR, communicating the result of the auctionin terms of tokens awarded for IN service re-quests;

Ø MB_AuctionDistributionInformation,sent from the MB-DISTRIBUTOR to the MB-QUAN-TIFIER, is an ‘acknowledgement’ required by theMB-QUANTIFIER to determine network delay.However, it could also be used to communicateinformation that the MB-QUANTIFIER can use in

Žmore sophisticated ways e.g., learning traffic.patterns .

To develop a FIPA-compliant multi-agent systemthese MSCs need to be implemented using FIPAACL performatives and protocols.

To implement the registration MSC, we use theFIPA-request protocol. This allows an agent to re-quest another agent to perform an action; for thatagent to agree or refuse the request; and, if agreed, atsome future time to perform the action and informthe original agent of the result.

In our case, an MB-QUANTIFIER or MB-ALLOC-ATOR sends a request for the MB-DISTRIBUTOR toperform a register action. To ‘do’ a register action,the MB-DISTRIBUTOR needs to agree with the MB-QUANTIFIERrMB-ALLOCATOR the data format, thetime format, and to synchronise clocks. If thesenegotiations are completed successfully, the MB-


DISTRIBUTOR will register the MB-QUANTIFIERrMB-Ž .ALLOCATOR and send an inform done message. The

protocol is illustrated in Fig. 6:The FIPA protocol notation is deficient in a num-

ber of respects, and so we use the Finite Statew xDiagram representation favoured by Pitt et al. 20 .

The following conventions are used:Ø The state of the protocol is labelled with

whichever agent should send the next message;Ø A square state indicates that some other action is

required before that state can be exited;Ø The protocol start ‘state’ is indicated by a thick

border;Ø Transitions between states are represented as arcs

labelled with the performative that ‘causes’ them;Ø States with no outgoing transitions are end states:

these may be states where the protocol has termi-Ž .nated successfully marked with a tick and those

Žwhere it ended unsuccessfully marked with a.cross . It is noted that indication of successr

failure of the protocol is important as agents needto reason about success or failure of their attemptto achieve goals – the reason for an agent toinitiate a dialogue is to achieve a specific goal.

Fig. 6. Registration Protocol.

The protocols used for time format and dataformat agreements are simple variants of FIPA pro-

Žtocols for accepting or rejecting proposals for de-w x.tails see MARINER Deliverable 3 16 . The proto-

col for clock synchronisation is discussed in Section4.2.

The performatives and protocols for describingMARINER auctions are more problematic. There arevarious reasons for this, including:Ø There is no given FIPA protocol for implement-

ing the kind of auction required for MARINER;Ø Using FIPA performatives to define a new proto-

col conflicts with the specified semantics;Ø It is not clear that the content of MARINER

messages should, in FIPA terms, be an action, aproposition or a definite descriptor;

Ø The real-time requirements are not captured bythe FIPA diagrammatic representation.Therefore, using another notation from Pitt et al.

w x20 , we specify the MARINER auction as:

MB-ALLOCATORS: set of MB-ALLOCATORS regis-tered with an MB-DISTRIBUTOR

MB-QUANTIFIERS: set of quantifiers registered witha distributorMB-DISTRIBUTOR, MB-ALLOCATORS, MB-QUANTI-FIERS: MARINER-auctionsŽ . �Ž . <1 Bids s MB-ALLOCATOR, bid 'MB-AL-LOCATORgMB-ALLOCATORS and MB-ALLOC-ATOR: MB_AuctionServiceRequest>

4MB-DISTRIBUTOR within timeout5 �Ž . <Offerss MB-QUANTIFIER, offer 'MB-QUANTI-FIERgMB-QUANTIFIERS and MB-QUANTIFIER: MB_AuctionServiceOffer ™ MB-DISTRIBUTOR

4within timeoutŽ . Ž2 MB-DISTRIBUTOR: auction Offers, Bids, Re-

.sultsŽ . Ž .3 ; MB-ALLOCATOR, tokens gResults.

MB-DISTRIBUTOR: MB_AuctionTokenDistribution™MB-ALLOCATOR within end_of_timeslot5 Ž .; MB-QUANTIFIER, tokens gResults. MB-DIS-TRIBUTOR: MB_AuctionDistributionIn-formation ™ M B -Q U A N T IFIE R w ithinend_of_timeslot.

This can be expressed in terms of FIPA performa-tives enhanced with real-time information that

ŽMARINER agents can act upon e.g., the need to.make a reply within a certain time . However, work-


ing to the FIPA specification is highly constraining,because the application is somewhat different fromthose for which the FIPA protocols, performativesand their semantics were originally devised. Wereturn to this issue in our evaluation of FIPA inSection 5.

4.1.2. MARINER content languageWe have chosen XML as a content language for

MARINER because it is expressive enough for ourpurpose and because it will become a widely usedstandard in the years to come. The XML family ofstandards includes Document Type DefinitionsŽ .DTD and a standard Resource Description Frame-

Ž .work RDF for translation between DTDs as well asa hyper-linking standard, XLink and XPointer Lan-

Ž .guage XLL , for combining XML documents. Fur-thermore, we have the style standard Extensible Style

Ž .Language XSL , a subset of Document Style Se-Ž .mantics and Specification Language DSSSL and a

Ž .Meta Content Framework MCF to provide informa-tion about information. Major vendors support theXML family of standards and new tools are devel-oped continuously. It might not be immediately obvi-ous that XML is a suitable content language for ACLmessages – after all, the main motivation for XMLis the exchange of documents via the Internet. How-

Žever, the notion of documents underlying XML and.Standard Generalized Mark-up Language, SGML

comprises a lot more than the HTML documentscurrently used for encoding web pages. And fromthis broader perspective, the content of an ACL

Žmessage clearly is a document. One could evenargue that the ACL message as a whole should beencoded in XML rather than in the current ACLformat, but this is an issue which would require thechange to the respective parts of the FIPA’97 speci-

.fications.Rather than being a language for encoding docu-

ments directly, XML is more a framework for speci-fying languages for document encoding, i.e., DTDs.In order to use XML as content language we thushave to do the following:Ø Define a DTD for the contents of MARINER

ACL messages;Ø Write or integrate a parser which parses XML

messages;

Ø Write an XML handler which processes the infor-mation passed to it from the XML parser.Here we will only illustrate the MARINER con-

tent language with two examples. The first exampleis a part of the MARINER DUD, namely the entitiesdefining a registration request:

-!ELEMENT registrationRequestEMPTY)

-!ATTLIST registrationRequestid CDATA #REQUIRED

<type (allocator quantifier) #RE-QUIRED)

This definition basically says that a registra-tionRequest does not contain any further elementsand has two mandatory attributes: the ‘id’, whosevalue is of type CDATA, i.e., is an arbitrary string,and the ‘type’, whose value is either ‘allocator’ or‘quantifier’. Given this definition the actual contentof a registration request would then look like this:

-?xml version= )1.09?)

-!DOCTYPE registrationRequestSYS-TEM)mariner.dtd9)

-registrationRequestid=)scp19

type= )quantifier9/)

The second example is taken from the auctioningprocess and describes the format of the service re-quests sent from allocators to distributors. First theDTD definitions of the format:

-!ELEMENT serviceRequest(arrivalPrediction)+)

-!ATTLIST serviceRequesttimeSlot CDATA #REQUIRED)

-!ELEMENT arrivalPredictionEMPTY)

-!ATTLIST arrivalPredictionservice CDATA #REQUIREDprediction CDATA #REQUIRED)

Note that this DTD is more complex than thefirst: a service request is defined as a list of arrivalpredictions with at least one member, where anarrival prediction is not further structured but hastwo attributes.

And now a concrete example for the content of aservice request message:

-?xml version= )1.09?)

-!DOCTYPE serviceRequest SYSTEM‘mariner.dtd9)


-serviceRequesttimeSlot= )239)

-arrivalPredictionservice= )service19

prediction= )39/)

-arrivalPredictionservice= )service29

prediction= )29/)

-/serviceRequest) .

4.2. Clock synchronisation

The agents that will implement the load controlstrategies discussed previously are linked to physicalworld entities such as SSPs and SCPs. Events in the

Žphysical world such as an incoming service request,.for example , are not only significant in that they

occur, but the time at which they occur is also ofimportance. The agents therefore need to be aware oftime. Yet, maintaining a global, single-valued viewof time in a distributed computing environment suchas an IN is virtually impossible. In practice, thenon-deterministic nature of network delays as well asvariations in clock frequency due to manufacturingand temperature, result in a wide range of clockvalues in a single instant over the whole of thedistributed environment. To combat this problemthere are three main time transfer protocols in usetoday. These are Christian’s Algorithm, the Berkeley

( )Algorithm and the Network Time Protocol NTPw x17 .

The overall clock synchronisation architecture wewill apply is depicted in Fig. 7. Clock synchronisa-tion is maintained at three different levels: the auc-

Ž . Ž .tion level 1 in the figure , the inter-domain level 2Ž .and the uniÕersal level 3 . The inter-domain level

relates to the potential enhancements of the loadcontrol strategies to allow for control of IN trafficpassing between the networks of two different opera-tors – for example an agent could be involved in two

Ž .auctions one for each network domain concur-rently. Potential strategy enhancements will be dis-cussed in more detail in Section 6.

In MARINER, the unit of atomicity of clocksynchronisation is taken to be a single auction, thatis, clocks of participants in an auction are required tobe synchronised if the auction is to be completedsuccessfully.

Fig. 7. Clock Synchronisation Architecture.

Within a single auction the MB-DISTRIBUTOR

functions as the central point of reference – everymessage is exchanged ‘through’ an MB-DISTRIBU-TOR. It is sufficient, therefore, that the MB-QUANTI-FIERrMB-ALLOCATOR clocks are synchronised withthe MB-DISTRIBUTOR’s clock. Christian’s Algorithmlends itself well to this kind of synchronisation.

For the intra-auction synchronisation, we havew xdefined the MARINER-clocksync-C protocol 16 ,

which is an adaptation of Cristian’s Algorithm to theFIPA standard of messaging. The query-ref perfor-mative allows one agent to ask another agent for theobject referred to by an expression. The inform-refperformative allows the sending agent to inform thereceiving agent of the object which corresponds to a

Ž .definite descriptor in our case, the time .There are advantages in extending clock synchro-

Ž .nisation across multiple auctions inter-domain level .As mentioned above, this will aid in cases where asingle MB-QUANTIFIERrMB-ALLOCATOR participatesin more than one auction simultaneously. Since thereis no clear primaryrsecondary relationship betweendifferent MB-DISTRIBUTOR’s, the Berkley Algorithmis used to synchronise clocks at this level.

For inter-domain synchronisation, we have de-w xfined the MARINER-clocksync-B protocol 16 ,

which is an adaptation of the Berkley Algorithm tothe FIPA standard of messaging. MARINER-clock-sync-B requires one MB-DISTRIBUTOR to function as

Ža master. Any suitable method e.g., lowest network.address may be used for the election of the Master

MB-DISTRIBUTOR. The protocol itself is based on theFIPA query-ref and inform-ref performatives also.


In the above protocols, time tokens are based onŽ .the standard Universal Co-ordinated Time UTC

ŽNTP format i.e., seconds since 00:00 on 1 January,.1900 . Finally, although there is, strictly speaking,

no need to do so, agreement between ‘MARINERtime’ and standard UTC time can be maintained by

Ž . Žreferencing external UTC time server s universal.level . In this case, synchronisation between MB-

DISTRIBUTORS can also be done with Christian’sAlgorithm, with every MB-DISTRIBUTOR being syn-chronised to an external UTC time source.

5. Evaluation and assessment

The work described in Section 4 focused on thedesign of a real-time multi-agent system for imple-menting the co-operative market IN load controlstrategy. This design is intended to conform to theFIPA’97 specification Parts 1 and 2, concerned withAgent Management and Agent–Agent Communica-tion.

In trying to be compliant with the FIPA specifica-tions for the MARINER application, we encountereda number of uncertainties with the interpretation andapplication of the ACL. This is, perhaps, not sosurprising, as the FIPA’97 ACL was aimed at ad-dressing the requirements of the applications speci-fied in Parts 4–7 of FIPA’97. None of these have

Ž .real-time requirements. Instead, this work a sug-gests work items where the specifications may bene-

Ž .fit from clarification andror refinement, and bprovides experience from which other agent systemsdevelopers can hopefully benefit.

In Section 5.1 we very briefly review three areaswhere we believe the FIPA ACL is proving problem-atic andror can be improved, and in Section 5.2some issues relating to ACL message sizes and agentaddressing are discussed. Finally, in Section 5.3 theabsence of support for real-time applications in theFIPA model is addressed.

5.1. FIPA ACL

5.1.1. ACL semanticsThe FIPA’97 Specification Part 2 which specifies

the ACL for inter-agent communication is loosely

based on speech act theory. It is therefore defined interms of a set of performatives, each of which isgiven a semantics informally via an English descrip-tion. Formally, a semantics is given in terms ofaxioms of a first order multi-modal logic. The inten-tion is to provide an intended meaning to act asguidance for developers, and a precise meaning thatcan be checked for compliance and discriminatebetween new performatives.

In designing the message passing for MARINER,we encountered situations where our intuitive inter-pretation of the FIPA performatives was consistentwith an English description but slightly differentfrom the formally specified semantics. Examplesinclude: an agent that was periodically updating in-formation, an agent wanting to confirm previouslyagreed information, and an agent wanting to selec-tively update information. This was due to theMARINER application having a rather different fo-cus than the application that motivated the FIPAACL semantics. However, the FIPA performatives isnot a closed set, and the formal semantics enables

Ž .new performatives e.g., as needed by MARINERto be clearly distinguished from the standard perfor-matives.

Application and interpretation of the FIPA speci-fications is discussed at some length by Pitt and

w xMamdani 21 . This paper concludes that there areŽissues to be resolved with the FIPA ACL and it will

.be addressed in FIPA’99 . However, MARINER hasendeavoured to work with what is available for thebest performance of the MARINER application. Itturned out that the motivation for the given protocolswas especially useful in the design of registrationand negotiation procedures. Some interactions in theMARINER multi-agent system were then designedon the basis of the standard performatives and proto-cols, with the semantic specification providing clearscope for defining new protocols and performativeswhen those proved to be necessary.

5.1.2. PerformatiÕes and protocolsOne practical issue that all agent communication

languages need to address, including FIPA ACL, iswhether the performatives are supposed to be ameta-level classifier for the communicative act or anobject-level verb used in the communicative act. In


practice, the choice of performatives is most likely tobe determined by the granularity of the application,in the same way that refinement of predicates inknowledge bases for knowledge representation issimilarly constrained.

For example, consider the ‘speech act’ propose.In ‘natural language’ this could be either ‘I propose

w xthat you do for me some action A ’ or ‘I proposew x Ž .that I do for you some action A ’ i.e., an offer . It is

possible to formulate these two sentences as speechŽ .acts in at least three different ways, trading off

abstraction in the performative with more explicitrepresentation of information in the content.

The actual formulation, though, will be con-strained by the application requirements and shouldbe the decision of the agent system designer: it is notreally something that can easily be standardised.FIPA’99 should address this reification issue, andprovide guidance for designers to choose betweenhigh abstraction and explicit content representationand vice-versa.

5.1.3. Transmission of agent communicationsA message sent in ACL format with a content

encoded in XML is much larger than the core infor-mation being transmitted. For example, in MARINERa Õery simple message structure might be sufficient,e.g., consisting only of integers specifying the costsfor the respective services. Thus, a quantifier mightjust send the message ‘80 1 1 70’, which is to beinterpreted as: service 1 costs 80, service 2 and 3 arenot supported and service 4 costs 70.

The corresponding inform message sent in ACLformat with a content encoded in XML is incrediblyhuge compared to the above four integers, i.e., wewould have messages whose header is a lot biggerthan the actual content. Note that this overhead inmessage size is caused not only by the XML encod-ing of the content, but already by the encoding of theACL message itself.

However, we can reduce this overhead in messageŽsize. When an agent MB-QUANTIFIER or MB-ALLOC-

.ATOR registers with an MB-DISTRIBUTOR, it cannegotiate the data format in the :content slot of

Žauction results this possibility has in fact been de-.signed into our registration protocol . Auction results

then do not need to be encoded as ACL messages atall, except to the extent that we need to transmit

Žthem through the FIPA ACC we do not anticipateeach MB-QUANTIFIER and MB-ALLOCATOR opening adedicated communication channel with the MB-DIS-

.TRIBUTOR .The ACC should therefore allow for transmission

of ‘heavy’ full ACL messages, which agents mayexchange at a ‘command’ level for registration, etc.,as well as lightweight sub-ACL messages which area compressed representation of domain-specific in-formation exchanged at a ‘data’ level. This informa-tion, compressed and encoded in XML, can then bevery efficiently transmitted and interpreted.

5.2. Use of SS.7 for Inter-agent message transport

In the FIPA specifications there appears to be animplicit assumption that the underlying data commu-nication network used to transfer information be-tween remote agent platforms is based on the TCPrIPprotocol suite. Clearly this will not always be thecase, particularly in the telecommunications domain,

Žwhere there would be significant advantages in terms.of reliabilityrrobustness and cost effectiveness in

having agent systems deployed in network switchescommunicate via the already deployed SS.7 infras-tructure. The discussion in the previous section onthe size of messages passed between the agentsimplementing the co-operative market strategy is ofparticular relevance when it is considered that thesemessages must be transferred using SS.7. This sec-tion discusses issues relating to message size andagent addressing when using SS.7 as an externalcommunications transport between FIPA agent plat-forms.

The first significant difficulty with using SS.7 asan external communications transport for FIPA plat-forms arises from message size limitations placed bythe SS.7. FIPA Messages may be of arbitrary sizeand hence assume a connection-oriented transport.However, deployed SS.7 systems typically only sup-

Žport the ‘connectionless’ protocols class 0 and class.1 of the SS.7 Signalling Connection Control PartŽ .SCCP , hence only limited PDU sizes are sup-ported. In SS.7 systems conforming to the 1993

w xWhite Book specifications 12 this maximum PDUsize is 2K octets. This means that a FIPA agentplatform residing in an SS.7 environment wouldhave to ensure that messages are suitably small or


else implement some sort of minimal segmentationand re-assembly protocol on top of SCCP class 1 tosimulate a stream-based interface supporting arbi-trary message sizes. It is noted that as mobile FIPAagents of even modest complexity would requiremessages of a size greater than 2K octets for migra-tion, a FIPA platform transporting them over SS.7would require a suitable segmentation and re-assem-bly protocol.

The second, and perhaps more fundamental diffi-culty arises from the fact that FIPA addresses aredefined as an elaborated TCPrIP address, whereasSS.7 uses a different scheme, based on either aSignalling Point CoderSubsystem Number combina-tion or a Global Title. This implies that a FIPA’97platform using SS.7 as a transport would need to

Ž .support perhaps in the form of an agent proxyfunctionality that would be used by the ACC andindividual agents to translate between FIPA and SS.7addresses. However, this approach is still restrictiveas agents would be required to know when a FIPAaddress needs to be sent to the proxy for translation.A better solution would be to enhance the FIPAaddressing scheme so that it can support agents withmultiple addresses, each of which may be of adifferent type. Ideally this scheme would also beextendable, so that any number of addressing schemescould be supported.

A more detailed discussion of the issues involvedin the use of SS.7 as an agent platform external

w xcommunications transport can be found in 4 .

5.3. Real-time enhancements to FIPA specifications

Distributed real-time systems may be charac-terised as ‘supporting multiple computations on mul-tiple nodes which must closely co-operate as peers toco-ordinate their actions and share data so as toperform a program or application that none couldperform alone. This is similar to multitasking in acentralised multiprocessor, but with longer co-oper-ation time constants due to inter-node communica-tion latencies and the nature of the applications.Such co-operation requires that these computationsand nodes dynamically adapt themselÕes to retainoptimal serÕice aÕailability and predictability oftimeliness despite complex partial failures and re-coÕeries in the system, resource dependencies, and

oÕerloads. High degrees of trans-node co-operationnecessitate Õarious degrees of trans-node consis-

w xtency properties’. 14Any inter-operable real-time Agent platform will

probably fall into the category of a distributed real-time system. This is still a primary research area andis not well understood. The lack of a well definedstate of the art in this area when applied to tradi-tional computing architectures makes the task ofdefining requirements for agent-based systems in thisarea very challenging. However, it is possible tocharacterise some of the common requirements forreal-time and distributed real-time systems and try tofit them into an agent-based framework such as theFIPA architecture.

Many real-time requirements are highly imple-mentation dependent and as such independent of theFIPA architecture. This is clearly the case for therequirement discussed above that auctions be con-cluded before an unspecified deadline. It could thusbe asserted that the current FIPA specifications aresufficient to implement a real-time agent system on

Žone platform or a network of homogeneous plat-.forms . Any extensions to the FIPA model are only

necessary to allow networks of heterogeneous FIPAcompliant real-time agent platforms. Of course theseextensions would also be useful in structuring asingle platform to support real-time activities.

When considering real-time agent platform re-quirements, there are three areas of interest:Ø Features of real-time applications that must be

addressed at the level of the FIPA model;Ø Features of real-time applications that may be

addressed at the level of the FIPA model;Ø Features of real-time applications that may be

suitable for standardisation as FIPA real-timeplatform agents.

5.3.1. Mandatory changes to FIPA architecture forreal-time systems

5.3.1.1. Support for communications transport proto-cols other than the TCPr IP suite. The current FIPAmodel has an implicit dependence on the TCPrIPprotocol suite through both the form of addressinginformation and the need for arbitrarily sized ACLmessages which implies a connection-oriented proto-col. Most real-time applications use specialised reli-


able protocols rather than TCPrIP and these must besupported in a credible real-time Agent Platform. Anenhanced real-time transport service requirementsstatement would also be useful.

5.3.1.2. Real-time support in ACL. This is the corerequirement for building real-time agent systems be-cause without agents that support concepts of timeno real-time processing is possible. Expression oftime-based properties, temporal reasoning and sup-port for related concepts such as the utility andpriority of an action is essential to these systems.Some of this information is suitable for including inthe content of a standard FIPA message, but some ofit should have repercussions for the use of the com-putational infrastructure and hence should be placedin the ACL header fields themselves.

5.3.2. Possible changes to FIPA architecture

5.3.2.1. Support for fault tolerance. As the funda-mental property of real-time systems is their pre-dictability, a degree of fault tolerance must be sup-ported in any real-time platform. In some cases thismay be achieved through underlying mechanismswhich are transparent to individual agents. Alterna-tively it may be necessary to add explicit support forredundancy and recovery in agent systems. This maytake the form of ACL extensions or additional man-agement capabilities specified for the AMS in theFIPA platform.

5.3.2.2. Quality of serÕice framework. Not all sys-tems have equal demands on their infrastructure anda QoS framework is a way for these differing needsto be expressed, especially in a distributed environ-ment where different platforms may be running ondifferent types of nodes. This would also add to thevocabulary of agent interactions and perhaps someinteraction protocols could be introduced whichwould simplify processing of this information.

5.3.3. Possible new system agents for real-time plat-forms

5.3.3.1. Scheduling agent. In closed, fixed-priorityreal-time system it is often possible to solve theconcurrency requirements by using external tools

and a scheduling entity. In a FIPA real-time platformit may be useful to define a scheduling Agent whichcould perform this role. This would have the effectof allowing interworking platforms’ schedulingagents to negotiate either for overall control of thecombined system or for appropriate combinedscheduling policies that would serve the needs of the

Žagents on both platforms. For many systems and for.all dynamically changing systems there is no known

analytical optimal scheduling solution and even off-line computational methods are insufficient. Therehas already been some work on using AI systems for

w xscheduling in these cases 25 . It may be possible touse the scheduling agent to actually implement thefuzzy logic required to perform dynamic schedulingfor these systems. If this were feasible it wouldrepresent a huge leap forward in the area of dynamicscheduling for real-time systems.

5.3.3.2. Time serÕice. All distributed real-time sys-tems need some form of Time service to support theuniversal awareness of time. In an agent system thismay just be a software component, but the propertiesof this service should be evaluated with respect tothe utility of making it an Agent in a real-time FIPAplatform.

5.3.3.3. Resource management serÕices. Typicallyreal-time systems ensure predictability by havingvery controlled use of system computational re-sources such as processes, threads, communicationspaths, etc. A real-time agent platform must be awareof this at an implementation level, it may be desir-able to expose this to the agents in the system so thatthey may co-operatively utilise the resources. Anobvious advantage of this would be in support ofmobility in real-time agent platforms where an agentwishing to move to the platform would have torequest suitable resources on the platform beforetransferring to it.

6. Conclusions and future work

This paper has provided an overview of workdone to date concerning the specification of a multi-agent system for realising a market-based and an


ant-based IN load control strategy. We have brieflydescribed the intended operation of both strategiesand described the inter-agent communications forrealising the market-based strategy in terms of FIPAACL performatives and protocols.

These specifications are somewhat preliminary innature, they may require further modification to al-low re-alignment with further developments of theload control strategies. Potential strategy enhance-ments not discussed here include multiple decen-

Žtralised auctions forming a potentially self-organis-.ing tree and variation of timeslot and token validity

duration for the market-based strategy; use of AB-ANTS to affect SS.7 routing in the ant-based strategy;development of an integrated marketrant strategy;and enhancement of strategies to operate in multi-op-erator domains. Additionally the strategies will beimplemented in a prototype trial environment-basedon commercial agent platforms, which may result inadditional modifications resulting from practical ex-perience with applying FIPA specifications.

Also of interest is an analysis of the overheadsassociated with the operation of the agent-basedstrategies described here. In this regard there are twoconcerns: firstly, whether the computational andcommunication overheads associated with the twostrategies mean that they compare unfavourably totraditional node-based control mechanisms; and sec-ondly, whether the overheads associated with imple-mentation of the strategies as FIPA agents outweighthe advantages of the use of the agent approach.Future work will concentrate on providing a quanti-tative analysis of both of these aspects.

The paper reported on a number of issues thatarose whilst applying the FIPA specifications to aspecific application. The main issues can be sum-marised as follows:Ø There appear to be a number of problems relating

to interpretation of ACL semantics-based on agentbeliefs, desires and intentions included in theFIPA’97 specifications;

Ø The ACL performatives as currently defined ap-pear to constrain the agent system designer’s

Žchoice between high abstraction i.e., treat theperformatives as meta-level classifiers of the

.communicative act and explicit content represen-Žtation i.e., treat them as the actual verb for that

.communicative act and vice-versa;

Ø In many applications a message sent in ACLformat with a content encoded in an arbitrary

Ž .content language such as XML will be muchlarger than the core information being transmit-ted. For application domains where bandwidthavailability is limited this could be a severe limi-tation, thus there appears to be a need for mecha-nisms to reduce the overhead in ACL messagesizes;

Ø The FIPA addressing scheme is based on elabo-Ž .rated TCPrIP address URL and thus will not be

suitable for use with a number of domain-specificŽ .communications protocols such as SS.7 . This

signals a need for a more flexible and extendableaddressing scheme.

Ø Current FIPA specifications have virtually nosupport for real-time inter-operability betweenheterogeneous agent systems. Potential enhance-ments to FIPA specifications to support real-timeapplications include support for communicationstransport protocols other than TCPrIP, real-timesupport in ACL, fault tolerance support, a qualityof service framework, resource management ser-vices, a time service and a scheduling agent;Future work with regard to FIPA will focus on

developing suitable solutions to the problems identi-fied above. It is hoped that development of the FIPAspecifications in terms of these issues will make theprospect of deploying agent-based solutions to prob-lems like load control a more viable propositionfrom the point of view of telecommunications net-work operators and equipment vendors.

Acknowledgements

This work was supported by the EC-funded ACTSproject MARINER; the authors wish to acknowledgethe valuable contribution that their colleagues inMARINER have made to this paper.

References

˚w x1 A. Arvidsson, S. Pettersson, L. Angelin, Profit optimal con-gestion control in intelligent networks, in: W. RamaswamiŽ .Ed. , Teletraffic Contributions for the Information Age, vol.B, Elsevier, Amsterdam, 1997, pp. 911-920.


˚w x2 A. Arvidsson, B. Jennings, L. Angelin, M. Svensson, On theuse of agent technology for load control, with an example IN‘Market-Based’ Strategy, in: Proc. 16th International Tele-traffic Congress, Edinburgh, June 1999.

w x3 A.H. Atai, B.S. Northcote, AIN focused overloads – areview of USA CCS network failures and lessons learned,ITC Mini-Seminar on Engineering and Congestion Control inIntelligent Networks, Melbourne, April 1996.

w x4 R. Brennan, B. Jennings, T. Curran, SS.7 as an agent plat-form message transport protocol, in: Proc. IS and N99,Barcelona, Spain, April 1999.

w x Ž .5 S.H. Clearwater Ed. , Market-Based Control, World Scien-tific, Singapore, 1996.

w x6 G. Di Caro, M. Dorigo, Mobile agents for adaptive routing,in: Proceedings of the 31st Hawaii International Conferenceon Multi-Agent Systems, Big Island of Hawaii, January 6-9,1998.

w x Ž .7 Foundation for Intelligent Physical Agents FIPA , informa-tion available at http:rrwww.fipa.org.

w x8 M. Gibney, N. Jennings, Market-based multi-agent systemsfor ATM network management, in: Proc. 4th Communica-tions Network Symposium.

w x9 J. Harju, T. Karttunen, O. Martikainen, Intelligent Networks,Chapman and Hall, London, 1995.

w x10 IEC, Web ProForum Intelligent Networks Online Tutorials,available at http:rrwww.webproforum.comrwpf_intelli-gent.html.

w x11 International Telecommunications Union, Q.12xx SeriesRecommendations – Intelligent Networks, ITU-T, 1993.

w x12 International Telecommunications Union, Q.7xx Series Rec-ommendations – Signalling System No. 7, ITU-T, 1993.

w x13 B. Jennings, F. Lodge, T. Curran, A strategy for the resolu-Ž .tion of signalling system No. 7 SS7 and intelligent network

Ž .IN congestion control conflicts, in: Proc. IEEE Interna-Ž .tional Conference on Communications ICC , Atlanta, 1998.

w x14 E.D. Jensen, A real-time manifesto, http:rrwww.real-time-os.comrrtmanifestorrtmani_0.html.

w x15 ACTS Project MARINER, information available athttp:rrwww.teltec.dcu.iermariner.

w x16 MARINER Consortium, Project Deliverable 3 – Initial Spec-ification of Multi-Agent System for Realisation of LoadControl and Overload Protection Strategy, available athttp:rrwww.teltec.dcu.iermarinerrpublic.html.

w x17 D.L. Mills, Improved algorithms for synchronising computernetwork clocks, IEEErACM Transactions on Networking 3Ž . Ž .3 1995 245–254.

w x Ž .18 Object Management Group OMG , information available athttp:rrwww.omg.org.

w x19 X.H. Pham, Congestion control for intelligent networks, in:Proceedings of 1992 International Zurich Seminar on DigitalCommunications, Intelligent Networks and their Applica-tions, Zurich, 1992.

w x20 J. Pitt, M. Anderton, J. Cunningham, Normalised interactionsbetween autonomous agents, Computer-Supported Co-oper-

Ž .ative Work 5 1996 201–222.w x21 J. Pitt, A. Mamdani, Some remarks on the semantics of

FIPA’s Agent Communication Language, 1998, available at

whttp:rr-teltec.dcu.iermarinerrdocsr4009in-b1 FIPA-ACL-xSems .doc.

w x22 R. Schoonderwoerd, O.E. Holland, J.L. Bruten, Ant-likeagents for load balancing in telecommunications networks,in: The First International Conference on AutonomousAgents, ACM Press, 1997.

w x23 XML – Extensible Mark-up Language, information availableat http:rrwww.oasis-open.orgrcoverrsgml-xml.html.

w x24 F. Ygge, Market-oriented programming and its application topower load management, University of Lund, Sweden, Ph.D.Thesis, 1998.

w x25 M. Zweben, M.S. Fox, Intelligent Scheduling, Morgan Kauf-mann, Palo Alto, CA, 1994.

Brendan Jennings graduated with a B.Eng. in Electronic Engineering from

Ž .Dublin City University DCU in 1993.He then joined Teltec Ireland DCU as aresearcher and Ph.D. student. He hasundertaken contract work for a numberof Irish companies and participated in anumber of collaborative research pro-jects, including ACTS-MARINER, forwhich he is Project Manager. His re-search interests include Intelligent Net-works, Load Control and Multi-AgentSystems.

Rob Brennan is a research officerworking in Teltec Ireland, Dublin City

Ž .University DCU . He has an honoursŽ .degree in Applied Physics DCU 1992

and an M.Sc. in Computational ScienceŽ .Queens University Belfast 1994 . From1994 to 1997 he was employed by ISO-COR, a vendor of standards-based direc-tory and messaging products. He is cur-rently pursuing a Ph.D. in the area ofagent technology at DCU.

Rune Gustavsson is at present profes-sor in computer science at the Univer-sity of KarlskronarRonneby. He is andhas been actively participating in severalinternational R&D projects. His presentinterests include practical and theoreti-cal aspects of multi agent systems. Thistheme is also the focus of the research

Ž .group, Societies of Computation SoC ,he is heading. URL: www.sikt.hk-r.ser;socr.

Robert Feldt graduated with a B.Sc. in Software EngineeringŽ .from the University of KarlskronarRonneby HK-R in 1997.

Whilst pursuing an M.Sc. he was employed as a research assistantŽ .by the Societies of Computation SoC group at the university.

During this time he participated in a number of projects concern-ing agent technology, including ACTS-MARINER. His main re-search interest is development tools for agents.


Jeremy Pitt is a lecturer in the Intelli-gent and Interactive Systems group inthe Department of Electrical and Elec-tronic Engineering at Imperial College,London. His research is primarily fo-cused on the intersection of Human-Computer Interaction, Artificial Intelli-gence and Digital Communication Ser-vices. He is Principal Investigator on theUK EPSRCrNortel Networks fundedproject CASBAh, developing a commonagent service brokering architecture and

the EU-funded projects MARINER and MAPPA, which is devel-oping a multi-agent architecture for persistent personalised accessto multimedia services.

Konstantinos Prouskas is a ResearchAssistant in the Intelligent and Interac-tive Systems Group of the Imperial Col-lege of Science, Technology andMedicine, University of London. He isalso currently working towards his Ph.D.in the field of real-time multi-agent sys-tems. He has an M.Eng. degree in Infor-mation Systems Engineering from Impe-rial College.

Joachim Quantz has studied ComputerŽ .Science Diploma in 1998 , Philosophy

Ž .and Linguistics Master in 1992 . In1995 he received a Ph.D. in ComputerScience from the Technische Universitat¨Berlin for his thesis on ‘PreferentialDisambiguation in Natural LanguageProcessing’. Since 1988 he has workedin several international projects on infor-mation systems, speech and languagetechnology and internet applications. Heis Project Manager for agent technologyprojects at IKVqq GmbH.

Documents

FIPA-compliant agents for real-time control of Intelligent Network traffic