Intelligent, autonomous and mobile software agents introduce an alternative approach that ... For example, in 1997, the global E-Commerce market was estimated at. $10bn and ... a multitude of vendors, operators and customers. ... consisting of a multi-operator network model and a number of associated real-time agents ...
A Mobile Agent Brokering Environment for The Future Open Network Marketplace 1
2
1
David Chieng , Ivan Ho , Alan Marshall , and Gerard Parr
2
1
Advanced Telecommunications Systems Laboratory, School of Electrical and Electronic Engineering, Ashby Bld, Stranmillis Road, The Queen's University of Belfast, BT9 5AH Belfast, Northern Ireland, UK {d.chieng, a.marshall}@ee.qub.ac.uk 2 Telecommunication and Distributed Systems Group, School of Information and Software Engineering, University of Ulster at Coleraine, BT52 1SA Northern Ireland, UK {wk.Ho, gp.Parr}@Ulst.ac.uk
Abstract. The growth of commercial activities across networks has led to the network itself becoming a competitive marketplace with a multitude of vendors, operators and customers. In such an environment, users will ‘shop around’ for the best deals in terms of network financial costs and services. Intelligent, autonomous and mobile software agents introduce an alternative approach that facilitates expertise-brokering activities on behalf of the users. In this paper we present such an agent supported brokering scenario. The scenario involves interactions between Java-based mobile agents and an interactive model of the network. The paper describes how this prototyping environment can be used to examine the impact of mobile agents for brokering network resources in the future open network marketplace.
1
Introduction
Over the past few years, a diverse variety of services have been rapidly introduced into the network. These have allowed a tremendous growth of trading activities across the networks. For example, in 1997, the global E-Commerce market was estimated at $10bn and this is predicted to rise to $200-300bn, by 2002. Additionally, over the same period, the global multimedia market will quadruple, from $150bn to $600bn [1]. This growth has led to the network itself becoming a competitive marketplace with a multitude of vendors, operators and customers. In this environment, users will be able to choose from a wide range of network services, which provide different bandwidth requirements and various Quality of Service (QoS), and which will operate under different pricing schemes [2]. It is anticipated that marketable resources will not be limited to end-user services. According to [3], technical and market forces are driving evolution towards the Traded Resource Service Architecture (TRSA) model whereby network resources such as bandwidth, buffer space and computational power will be traded in the same manner as existing commodities. To cope with these fast changing and complicated trading environments, users, whether buyers or sellers, need tools that facilitate expertise brokering activities such as buying or selling the
right products, at the right price, and at the right time. This paper describes the use of intelligent mobile agent technology as a brokering tool for the various parties involved in a future network marketplace. In this paper, the trading of resources such as network bandwidth and end-user services is examined. Similar studies have been conducted by Gibney [4], where a market-based approach was used to allocate network resources. Here, cost is imposed on each link and traded by software agents. Sun Microsystems Laboratories and Agorics Inc., have also demonstrated a system whereby ATM network bandwidth can be traded in real time between a bandwidth provider and a video server, and between the video server and a client, with the assistance of the bidding agents [5]. Both studies have demonstrated the benefits of employing software agents for the brokering of the network resources. Section 2 gives a brief introduction to mobile agent technology and highlights its advantages over traditional client/server approach. A prototyping framework consisting of a multi-operator network model and a number of associated real-time agents, has been developed, and this is described in section 3. Section 4 explains the agent components' interactions and management. A number of case studies were carried out using this prototype system and their results are discussed in section 5. Section 6 presents the conclusions and some comments on the future directions for this work.
2
Mobile Agent Technology
Mobile Agent technology has been widely proposed as a key technology in the creation of an open, active, programmable and heterogeneous network environment. Many network systems employ client-server architectures which usually requires multiple transactions before a given task can be accomplished. This results in increased signalling throughout the network which can rapidly escalate, and reduce network utilisation as well as increasing the operating costs. An alternative approach is to dispatch a mobile agent to a host, where the interactions can take place locally, thus reducing the level of remote interactions required. Additionally, mobile agent executions are independent of both their runtime environments (i.e. operating systems) and the transmission system they transverse. Software agents can be delegated to complete specific tasks on their own, providing that a certain set of constraints or rules have been defined. With the ability to move across the network, a software agent is no longer bound to the system where it is created and executed. When an agent starts executing in a server and tries to request a service that is not provided by that server, the agent then saves its current state and process and moves itself to a particular network node which provides that service. Upon arrival, the agent unwraps its process and state and resumes execution there.
The attributes of a mobile agent can be classified as follows: Table 1. Mobile agent attributes and descriptions.
Attribute Autonomous Communication Cooperate Mobility
Description Agents can be proactive and able make autonomous decisions, based on their environment. Agents can communicate with one another. Agents can cooperate among themselves to achieve a task. The ability to move itself across any networks and platforms (Java-based).
There have been numerous works that have investigated the application of Mobile Agent technology to Network Management [6], [7] and [8]. Agent Technology offers an alternative solution to Network Management issues such as automatic network discovery, fault detection and more efficient bandwidth utilisation. This involves the remote execution and transmission of executable code between clients and servers in a distributed network environment. Hence, it becomes unnecessary to transfer intermediate data across the network. With the exponential growth on the usage of Internet, E-Commerce is another area in which agent technology can be adopted [9]. Using agent technology, buying or selling for a product on-line becomes more convenient. Users can predefine the constraints for a product or service by which the agent would buy or sell for before it is launched into the network. In order for mobile agents to work in a heterogeneous network, a platform independent programming language is necessary. Java has become the de facto language for creating mobile agents. Java offers portability, automated garbage collection and memory management required by agents. An agent environment framework is also required for the implementation, execution and management of agents. Several commercial agent frameworks have been developed such as ObjectSpace Voyager [10], IBM Aglet [11], General Magic Odyssey [12] and Meitca TM Concordia [13]. The ObjectSpace voyager ORB version 3.0 has been adopted for the implementation of our Agent prototype system solely because of the detailed documentation available on the framework, the ability to construct remote objects in the remote host and a set of control mechanisms that offer more flexible instructions on how the agent should terminate itself. There are two types of communication TM mechanism, namely Method Calling and ObjectSpace by which the Voyager agents interact with each other. The former mechanism enables an agent to call methods of another agent. This requires that the calling agent knows a-priori the method interface of the called agent. The latter mechanism enables the voyager agent to multi-cast an event message to other agents. The level of intelligence in agents can range from hard-coded procedures to sophisticated reasoning and learning capabilities. The specific functions and requirements of an intelligent agent are the prime determinant of which techniques should be used. The amount of intelligence required by an agent is related to the degree of autonomy and the mobility that is required. If an agent must deal with a wide range of situations then it needs a broad knowledge base and a flexible inference
engine. If it is mobile, there may be a premium on having a small, compact knowledge representation and a lightweight reasoning system in terms of code size. For a software agent to perform actions, it must perceive events occurring around it, and have some concept of the state of its world by using sensors. A fundamental component of perception is the ability to recognise and filter out the expected events and attend to the unexpected. A software agent must be able to gather information about its environment actively or passively. The former involves sending messages to other agents or systems and the latter receives a stream of event messages from the system, the user or other agents. For example, in the context of an Interface Agent, it must be able to distinguish normal events (mouse movements) from significant events (double click on an action icon). In a modern GUI environment such as Windows or Xwindows, the user generates a constant stream of events to the underlying windowing system. The agents can monitor this stream and recognise sequences of basic use action as signalling some larger scale semantic event or user action. Once an agent has perceptively recognised that an event has occurred, the next step is to take some action. This action could be to realise there is no action to take or it could be to send a message to another agent to take an action. Intelligent agents use effectors to take actions either by sending messages to other agents or by calling application libraries or system services directly.
3
The Prototype Multi-Operators Network Model
In order to carry out research on the agent brokering system, a prototype network model has been developed using the Block Oriented Network Simulator (BONeS) [15] as an agent testbed. A scenario, which involves three competing networks and a system of associated agents, is illustrated in Figure 1. All NABs Provide TCP/IP Interface
NAB
Agents
Network A
Management Station
INAB
SP
NAB
Client
Network B
INAB
NAB
Network C
Fig. 1. Prototype Network Model for Agent Brokering Environment
CP
The scenario presents three individual networks owned by different operators; each is identical in terms of the number of devices, topology and available resources. Currently each network consists of nodes connected in a mesh topology. As a means of creating competition, all three networks offer the same access to a remote Content Provider (CP) which provides multimedia services such as voice, data and video. Network operators A, B and C will then be competing to sell their network links to clients through a representative agent host, the Network Access Broker (NAB). The Service Provider (SP) acts as a single point of contact between a Client and multiple NABs, rather than the client having their own negotiating agents hoping between multiple network hosts. Hence several different customers’ resource requirements can be aggregated together in order to achieve a lower cost to the individual [Greenwood, 2]. The NAB provides TCP/IP socket interfaces for software agents to communicate with the model. There is a Management Station (MS) for each network, and this maintains routing tables, network pricing, resource updates, other management information and network statistics. The Inter Network Access Broker (INAB) serves as an intermediary between two neighbouring networks. This allows negotiation for access to one another’s resources. This is useful if, for example, when Network A is unable to supply the requested bandwidth asked by a SP agent. Rather than turning down the request and hence losing potential revenue, Network A can buy supplemental bandwidth from Network B to compensate for the shortfall [Greenwood, 2]. Background traffic loads are supplied to the networks in order to create a dynamic, realistic scenario of a network system.
4
Agent Interactions and Simulator Interface
Figure 2 illustrates the system components and its agent interactions. Our agents are IPC (Inter Process Communication) enabled, and this allows them to interact with the Network Simulator using a predefined protocol. At this stage, the security issues have not been considered as essential for demonstrating the system. However, it is anticipated that future development of the agent system will need to address these issues. Customer Agent Service Provider Agent
Network Access Broker
Network Provider (BONeS Network Model)
Network Access Agent Content Provider Agent Local Agent - Manager Interface
Customer
Service Provider
Fig. 2. System Components and Agent Interactions
Content Provider
There are five component parties in this architecture: the Customer, Service Provider, Content Provider, Network Access Broker and the Network Provider, which constitute the agent system. Each component consists of its own database, agent(s) and a manager. The manager's job is to provide service for any arriving agent, handle data transactions, storage retrieval, agent creation and task assignment. Figure 2 shows that a customer agent requests a service by moving itself to the central service point (Service Provider) having being launched by the Customer and interacts with the local object (Manager), which contacts its server to create an agent and delegates tasks to it. The event diagram of general inter-agent interactions is illustrated in figure 3. Customer Manager
Customer Agent
creates agent, assigns tasks and sends it completed request, returns home
Service Provider Manager
requests service on behalf of user
Service Provider Agent
creates agent, assigns tasks and sends it
Network Access Manager
Network Access Agent
Content Provider Manager
Content Provider Agent
creates agent, assigns tasks if requested
requests service or negotiates
informs Customer & Service Provider of the result requests service or negotiate
creates agent, assigns tasks if requested
informs Customer & Service Provider of the result
Mobile Agent
Static Agent
Fig. 3. Event Diagram for General Inter-Agent Interactions
The Network Access Broker and Content Provider serve as the selling parties whereas the Service Provider agent acts as a customer representative for buying network resources and services.
Task List
Communication
Kernel
Security
Fig. 4. Agent Model
Negotiation
♦ ♦ ♦
Vector getMovieList(); void informCustomer(); boolean getConnection(double bandwidth, String destinationNode);
♦ ♦ ♦ ♦
ASPManagerI obtainASPManagerID(); VSPManagerI obtainVSPManagerID(); NABManagerI obtainNABManagerID(); CustomerI obtainCustomerID();
♦
boolean quoteConnectionCost(double customerOffer, double[] otherNetworkCost);
An agent must follow its task list in order to fulfil the assignment given by its manager as shown in figure 4. This list contains a set of operations that need to be carried out and the locations to be visited. An agent can alter the route plan depending on the surrounding environment. The kernel of the agent contains its agent ID and local memory for operational and task related processes. The communication component manages all communication between the agent and external parties. This extends to: (i) access to host sites and (ii) interaction with other local agents once resident. The negotiation component is responsible for managing the bartering process between the agents. At this stage only a very rudimentary form of negotiation has been implemented, enabling agents to request resources for a connection with bandwidth, QoS and cost requirements, directly from the local object (i.e. a NABManager). Finally, the security component has not yet been implemented but exists as a key constituent of the agent. The intention is to introduce an authentication mechanism, whereby an agent can be assured that a potential host or neighbour agent is non-malicious and vice-versa.
5
Case Studies
A case study framework that demonstrates the usage of mobile agents is presented in this section. 5.1
Part A – Hunting for the Best Deal (e.g. Movie and Network Connection)
We start with a user who wishes to download a movie list from a remote video provider site, Video Service Provider (VSPServer) into his/her PC. A GUI is provided to specify preferences and is shown in figure 5.
Fig. 5. Screenshot of Customer GUI
As illustrated in figure 6, the user's agent (CAgent) is launched into the network and arrives at the central service point, Access Service Provider (ASPServer) and contacts the local object (ASPManager) for movie list retrieval. After finishing the request, the CAgent returns to the Customer and waits for notification from ASPAgent launched by the ASPManager, the communication channel between the customer and ASPServer is closed during the waiting period. It processes the request and sends an agent (ASPAgent) to the VSPServer to contact the local object (VSPManager). The request is passed to the VSPManager that stores/processes the request and hands over the movie list to the ASPAgent. Before notifying the customer that the movie list has been retrieved, it returns to the ASPServer to store the information and data.
Injects CAgent
Customer
CAgent
0 Process request & response
1-Asks AManager for a movie list. 2-Returns to Client & waits for ASPAgent to bring back the result
ASPManager Process request & response
ASPAgent
6-Gives the CManager the movie list. 7-Returns to ASPServer. 8-Waits for instruction.
VSPManager
Injects ASPAgent
Injects ASPAgent
CManager
VSP Server
VSPAgent - Tells AManager a new movie is added. - Returns to VSPServer Waits for instruction
ASPServer ASPAgent 3-Asks VSP Manager for a movie list. 4-Recevies movie list from Manager. 5-Returns to ASPServer & store data.
Fig. 6. Getting Movie List
To get a network connection, a user’s mobile agent that contains a set of predefined criteria e.g. maximum afforded per view price and video quality is injected into the network. Upon arriving in the ASPServer as illustrated in Figure 7, the agent contacts the local object, the ASPManager for a service request. The request is then processed, stored and tasks are then delegated to an agent to query/negotiate the external entities (NABManager) which is resided in the remote host for that particular service. The ASPAgent visits all the NABServer (A, B and C) to get the respective quotations for the connection price according to its route plan. The inter-agent negotiation processes are shown in figure 8 and are recorded into the agent’s virtual base. The agent will return to the customer when the best deal is found. Currently, the predefined criteria for service request, e.g. the network connection, are embedded in the agent.
Injects CAgent
Customer
CAgent 1-Ask AManager for network connection 2-Returns to Client & waits for ASPAgent to bring back the result
0
Process request & response
Injects NABAgent
ASPManager Process request & response
Tells ASPManager network changes. Returns to NABServer Waits for instruction
Injects ASPAgent
CManager
ASPAgent 6-Inform Cmanager of result. 7-Returns to ASPServer. 8-Waits for instruction.
NAB Server
NABAgent
Injects ASPAgent
ASPServer
NABManager
ASPAgent 3-Ask Manager for network connection. 4-Negotiate connection cost. 5-If deal is done then return to ASPServer & store data.
Fig. 7. Getting Network Connection
Fig. 8. Agents Interaction GUI
5.2 Part B - The Impact of Pricing Strategy on Network Loads In part B, we present an associated scenario where the three network operators compete to sell their bandwidth by constantly changing their prices. This has an impact on their network loads. The specifications for this scenario are: • Users request for video services such as MPEG2 video stream from the VSP through ASP. • For preliminary studies, 10 units of fixed bandwidth (BW Unit) were allocated for each connection. 1 BW Unit can be abstractly defined as 1kbps, 100kbps or 1Mbps. In this case, 1 BW Unit can be considered as 100kbps.
• Since the maximum BW capacity per link is allocated as 100 units (10Mbps), therefore the maximum number of active connections at one time is 10. • The VSP provides all kind of video services such as MTV, News, Documentaries, Movies etc. Hence the duration for each connection is randomly set between 5mins to 180mins. • Users’ requests arrival rate for video services are according to a Poisson distribution and has an average of 7 requests per hour. • The users will choose the cheapest network as the only preference at this stage. In the future scenarios, QoS selections and negotiations will be considered. • The simulation is run for 2000 minutes or 33.33 hours (simulation time). Figure 9 shows the changes in price and the corresponding number of connections (i.e. network loads) for each network operator, over the period of time. Net A Cost
Net B Cost
Net C Cost
0.030 0.020
£
0.010 0.000 T0
T1
T2
T3
Fig. 9. No. of Active Connections Per Network at One Time.
The initial costs for all the networks are shown in time interval T0. The changes in price take place at the beginning of time intervals T1, T2 and T3 as displayed on the top of the graph. During time interval T0, Network A dominates the connection counts as shown because it is offering the cheapest connections. At T0 ≅ 200mins, Network B begins to get connections due to network reaching link saturation. Towards T0 +500, Network B begins to win custom through price reduction. This pattern continues with each network winning connections and revenue from one another through a combination of price reduction and competitor link saturation [Greenwood, 2]. From this rather straightforward pricing strategy, a question arises as to how many more price reductions can each network afford in order to constantly win/maintain
customers. A consensus is therefore necessary regarding profit margin, pricing policy, etc. Furthermore, winning too many customers at one time will cause network congestion and consequently lose potential future customers due to link congestion and QoS degradation. Figure 10 shows the breakdown of revenue generated by each network.
Revenue Generated 700 600 500
£
Network A
400
Network B
300
Network C
200 100 0 0-500
500-1000
1000-1500
1500-2000
Total
Time(Mins) Fig. 10. Revenue Generated at Time Intervals
Figure 10 shows the importance of setting the right price at the right time. Being the most expensive will result in losing all the customers. By contrast, offering the cheapest connection will lead to network congestion and a drop off in profit. In this simulation, users only pay at the end of the session. The calculation for revenue per connection is based on: Revenue = Cost/BW Unit * BW Used * No. of Links * Session Length (mins)
6
Conclusions and Future Work
In this paper we have discussed how mobile agent technology can facilitate brokering activities for network resources and services in the future open network marketplace. A prototyping framework, which consists of a multi-operator network model and a number of associated real-time agents, has been developed to enable analysis. The results show that the use of mobile agents introduces a much greater dynamic to the provision of network services. It is clearly seen that mobile agents have taken over most transactions and negotiation tasks, and therefore increase the speed of decision making according to user preferences. Furthermore this dynamic is accentuated by the increased competition (on a per service basis, rather than on per day or per week) which can be introduced into the market by agents representing new or aggressive network operators.
The interactions between a customer’s agent and the static object in the remote hosts relies heavily on the usage of the “future call back” method which is documented on the Voyager ORB version 3.0’s user guide [10]. Each agent has a set of tasks, and each task can be performed at the server, which provides a local object to interact with the mobile agent. The communication link between the Network Access Brokers and the network model is based on socket processing which is the only method to maintain the communication channel. In our current system, the ‘rulebased approach’ is applied to enable the agents to negotiate. Further developments are proposed for this framework. For the agent system, the communication between agents limits the syntax and semantic representation for a real negotiation to take place. In order to overcome this limitation, KQML [16] will be implemented to enable a realistic bargaining between agents. Security is another concern for the agent system; it prevents any hostile agent from violating another agent’s privacy. This introduces the implementation of a common place for all the agents to perform trading (i.e. a “virtual network marketplace”). Also, some forms of federation policy can be adopted to enable fair-trading between agents. The simulation will be enhanced to offer alternative paths through the network when congestion occurs. At the user level, service attributes such as QoS for movie viewing can be categorised in terms of Gold, Silver and Bronze. These may be provided as value added services in our future model.
Acknowledgement Funding from Fujitsu Telecommunications Europe Ltd. is acknowledged. Input from Dr Colin South and Dr Dominic Greenwood is also appreciated.
References 1. Foreword, Ian Morphett, Managing Director, BTUK, Products and Services, BT Technology Journal, Vol. 17 No.3, July 1999. 2. C. Philips and P. Kirby, 'ATM and the future of telecommunication networking', Electronics & Communication Engineering Journal, June 1999, pp.108-124. 3. D. Greenwood, D. Chieng, A. Marshall, I. Ho, G. Parr, 'Brokering Marketable Network Resouces Using Autonomous Agents', Submitted to World Telecommunications Congress/International Switching Symposium (WTC/ISS2000) conference, Birmingham, U.K., May 2000. 4. M.A.Gibney, N.R.Jennings, N.J. Vriend and J.M.Griffiths, 'Market-Based Call Routing in Telecommunications Networks using Adaptive Pricing and Real Bidding', IATA'99, Stockholm, Sweden, 1999. 5. Mark S. Miller, David Krieger, Norman Hardy, Chris Hibbert, E. Dean Tribble, 'Chapter 5: An Automated Auction in ATM Network Bandwidth', Market-Based Control: A Paradigm for Distributed Resource Allocation, Edited by S.H. Clearwater, World Scientific Publishing Hardcover, 1994, pp. 96-125. 6. R.G Davision, J Hardwick and M.Coz, 'Applying the agent paradigm to network management', BT technology Journal, Vol 16 No 3, July 1998, pp. 86-93.
7. D.Gavalas, M Ghanbari, D.Greenwood, M.O’Mahony, ‘A Hybrid Centralised Distributed Network Management Architecture’. 8. Andrzej Bieszczad, Bernard Pagurek, Tony White, ‘Mobile Agents for Network Management’, IEEE Communications Survey magazine, Sept 1998. 9. http://agents.www.media.mit/edu/groups/agents/projects/ 10. http://www.objectspace.com/voyager 11. http://www.trl.ibm.com/aglets 12. http://www.generalmagic.com/technology/odyssey.html 13. http://www.meitca.com/HSL/Projects/Concordia/ 14. http://www.infc.ulst.ac.uk/~phhwk/publication/IZS2000.htm TM 15. BONeS DESIGNERâ Ver 4.01, Alta Group of Cadence Design Systems, Inc. 16. T.Finin, "Specification of the KQML as an Agent Communication Language", http://www.cs.umbc.edu/lait/papers/kqmlspec.ps
