Dandenong Road, Caulfield East, Victoria 3145, Australia. {Glenn.Jayaputera, Oshadi.Alahakoon, Lito.Cruz, Seng.Loke,. Arkady.Zaslavsky}@csse.monash.edu.
Assembling Agents On-Demand for Pervasive Wireless Services Glenn Jayaputera, Oshadi Alahakoon, Lito Cruz, Seng Loke and Arkady Zaslavsky School of Computer Science and Software Engineering, Monash University, 900 Dandenong Road, Caulfield East, Victoria 3145, Australia {Glenn.Jayaputera, Oshadi.Alahakoon, Lito.Cruz, Seng.Loke, Arkady.Zaslavsky}@csse.monash.edu.au
Abstract. Wireless networking technology is bringing services and applications to more users with greater availability than ever. It is at the network edge that personalized services are presented and utilized by end-users. Mobile software agents deployed into these services can assist users such as content adaptation to deal with the great diversity of mobile devices and server-side information searching and gathering to improve efficiency. However, help is needed to generate and coordinate such agents, especially for non-technical users. In this paper, we present a multiagent system called eHermes, which can be used to provide such help. eHermes’ architecture and discussions on each major component are presented.
1
Introduction
Wireless network environment and mobile devices create many challenges that have not been adequately addressed in current traditional distributed systems. One of the issues is Quality of Services (QoS) such as line-rate, delay, throughput, round-trip time and error rate may change from one location to another. For example, moving from Universal Mobile Telecommunications System (UMTS) cell to a General Packet Radio Service (GPRS) cell may effect the throughput [1]. The second issue is related to monetary cost. This cost directly associated with the amount of data being transferred to the mobile devices. With many mobile devices being introduced to the market (such as PDAs, Palmtop, smart-phones, etc) and many of which are unable to display high-resolution graphics, transferring high-resolution images to those mobile devices is not feasible. The problem is exacerbated by the fact that some wireless networks have small throughputs and unreliable connection. Those conditions have driven software developers to create different systems that either provide: (1) content adaptation (scalability) or (2) information gathering for devices in wireless network environment [2] (e.g., where agents can be launched to filter information on the server-side even while the user is disconnected). By content adaptation we meant that the software is be able to scale the content being delivered to the target devices based on the QoS of the wireless network, devices’ capability and user’s preferences. The idea is, when the QoS of the network is not good then there is no need to send big data especially when those data are only for marketing purposes such as animated graphic files. Furthermore, since normally the user has to
pay the amount of data he has downloaded, then it makes sense to filter out those types of data when they are not required. The device capability also plays a role in this situation. Some devices are unable to display high-resolution images due to their internal hardware capabilities such as supported colour depth, buffer size, etc., and so, cannot handle graphical data. This paper describes how a system called eHermes, which, in a single framework can provide end-users with such services as mentioned. eHermes acts as a proxy between the user and Internet information resources. eHermes accepts request from a user, locate (and compute if necessary) the result and finally send the results back to the user, generating, deploying and coordinating the agents as needed. EHermes was developed for financial services domains, however, our technology is applicable to other domains as well. The rest of this paper is organized as follows. Section 2 discusses the general nature of the problem in wireless network environments. Section 3 reviews the architecture of eHermes and discusses each of its major components. Section 4 provides a simple usage scenario to illustrate how eHermes works in this context. Section 5 concludes this paper.
2
Background and Example
Wireless WAN is in the stage of rapid development. New technologies such as High Speed Circuit Switched Data (HSCSD) and UMTS are already in the market [1]. Direct implication to this progression is that performance will be significantly increased. However, the basic problem still remains the same. The value of QoS may change dramatically as the user moves from one location to another. Connections are interrupted as the user moves from one cell to another so that data retransmission is sometimes necessary. When the data is not so important (such as marketing graphic images) then it is necessary to filter out such data from being transmitted because the user has to pay the amount of data transferred to his/her device. It should be noted however, that this mechanism is not necessary when the user is in a wireless LAN and especially when he is using a powerful notebook. This requirement calls for a system to scale the content of the information being delivered to a minimal form based on some parameters such as the capability of the hardware devices being used, the quality of the wireless network, cost of data transfer, network bandwidth, etc. to name a few. With the help of the software agent technology [3], the user does not have to browse the result to find the right one, instead gets the system to find the answer, filter out those expensive and unnecessary images and finally deliver it to him. During the searching and filtering processes, the user can disconnect from the network and hence potentially save time and cost. This is just one application eHermes can be used for. Our studies reveal that at the moment software developers tend to build agents for a specific purpose. For instance, MORPHEUS [4], CHAYANI [5] and MAgNET [6] were developed specifically for on-line shopping; while a system like InfoSleuth [7] was developed to perform information extraction from heterogeneous on-line information sources. Each of these systems performs different tasks, yet some of their
tasks are the same or similar. We believe that such technologies are not suitable for wireless environment not only are they too ‘heavy’ to be stored in mobile devices; they are also not flexible1 and adaptive enough. While technology such as Web Clipping [8] is good for network-resident applications that require a richer display and more user interaction than typical WAP applications, it requires humans to browse to find the answer and hence is not a real cost saving solution. Furthermore, Web ® Clipping is developed for the Palm OS platform and hence is not a generic solution. Figure 1 shows eHermes between the users and online resources such as the Internet or databases. Instead of accessing these resources directly, the user sends a request to eHermes and lets it find and deliver the answer back to him. When eHermes received a request, it sends and coordinates mobile agents to find and collect result(s). Once the result(s) are found, eHermes will send it back to the user either in un-adapted or adapted fashions. The decision on whether to send un-adapted or adapted content will be based on: (1) the device capability, (2) wireless network QoS and (iii) user preferences. As shown in Figure 1, the content has adapted for the pocket PC users in a GPRS network; whilst none has been made for the users within a 802.11b network with a powerful notebook. GPRS Adap ted
On Line Resource
Content Reque st
Information
eHermes 802.11b
da Una
pted
e Cont
nt
st que Re
Figure 1. eHermes in Wireless Environment
Agent Components
Ontology
Mission Mission Generator
Resulti ng info
rm atio
Agent Generator
Mobile Agent
Request Information
Mobile Spec
Us Pr er ofil e
Mission Control Agent
Device Ty pe
Ontology
Mission
Profile Builder
Filter/Presentation
Figure 2. eHermes Architecture That is, they are domain specific.
M
n
Mission Control Agent (MCA)
e-Hermes
1
y
Ontology
Agent Component Library
Ontology
ol og
Mission Repository
nt
Static Information
User Interaction Processor
Filtered Result
Stereotype Library Stereotype
Actor
Profile Repository
Profiles
Request
Device Type
O
Ontology
M
3
eHermes
In eHermes, we use stereotype-based profiles [9] to provide customized services. A “User Profile” is a description of a user and a “Device Profile” is a description of a device. A stereotype is an example user profile that is common for a group of people. If an individual user belongs to a certain group depending on his properties, he inherits the properties in the group stereotype. eHermes has a repository of stereotypes for possible system users. The layout of the stereotype has two parts, they are: (1) Classification part, and (2) Predictive part. Classification part consists of 1. Context independent information: user’s demographic information, device information such as brand name, model number etc. 2. Context dependent information: user’s current location, user’s current environment (e.g. driving or he is in a noisy or dark surroundings). Predictive part has predictions about user’s needs, preferences and future behavior or device quality and performance. These predictions get a rating depending on the information in classification part. When a user or a device enters the system for the first time, eHermes initially maps that user or device to an existing stereotype. Then the predictive information in that stereotype is copied to the profile of that particular user or device. These values are used as starting information about the user and then personalized to build the profile of the person or device. The Mission is a key notion of eHermes. A mission is defined as a goal that the system must perform on behalf of the user. A mission is generated based on the user request and profile. eHermes is open in that it is generic as such that both mission and domain knowledge are supplied at run-time. The architecture of eHermes is presented in Figure 2. eHermes comprises of several modules such as User Interaction Processor, Profile Builder, Mission Generator, Agent Generator and Filter/Presentation modules. The following sub-sections briefly describe these modules. 3.1
User Interaction Processor
User Interaction Processor (UIP) is one of the major components of eHermes. It is responsible for carrying out all the interactions with the user. In this system we try to make the user interaction as unobtrusive as possible. That is, the system attempts to function with minimum input from the user. Figure 3a shows the UIP architecture. The UIP handling a user request can be described as follows. 1. Receives a user request (for a particular job, e.g. requesting information) and device information such as device name and model number. 2. When the system receives the device name it identifies the device type & passes it on to the profile builder processor. It should be noted that, it is assumed that eHermes has access to a database containing a list of names of a number of mobile devices in the market along with the device type. Also the system maintains a repository with possible profiles (stereotypes) for those device types. These stereotypes contain information such as the screen size, memory, available browsers etc of the device.
3. Analyse the user request using the domain specific vocabularies & ontology to find out information critical to the mission; pass it on to Mission Generator. 4. Prompt the user for minimum demographic information, such as: name, DOB, etc. Sends it to the Profile Builder Processor. 5. Finally, when the result arrives from the Filter/Presentation module, forward it to the user.
User Interaction Agent Request
Actor
Device type
Request + Device Name User Information + Final Results
Request Analyzer
User Information To Profile Builder Processor
Results From the Presentation Filter Processed request information To Mission Manager
Stereotyp e Library
Profile Repositor y
User Information Profile Builder Agent User Profile To Mission Manager Vocabulary (Ontology)
Analyzed User Informati on
User Informati on for profile building
Device Data
Search Agents Web Pages
Filtering Agents
Download Agents
Domain Specific Vocabularies
Figure 3a: User Interaction Processor
Figure 3b: Profile Builder Processor
3.2 Profile Builder Figure 3b shows the Profile Builder Architecture. The profile-building agent carries out work management in the profile builder processor. It takes User demographic information as the input and sends the personalized profile to the Mission Generator as the output. Following steps are required to build a personalized profile: 1. Pass the available user information to ”Search Agents”, to find more information on the user. The intention of the Profile Builder Agent is to collect as much information about the user as possible. A number of search agents are employed to find out regarding the user in different locations (heterogeneous information sources). 2. Search for a profile in the profile repository in the name of the user. If a profile exists it is updated using the information from Search Agents. If the search fails, then the profile-building agent will attempt to find the best matching stereotype for the user. The stereotype will then be modified using the information from Search Agents until it is best suited for that user. 3. Once the profile is completed, pass it on to the Mission Generator. There are three types of agent groups, within this process, they are: (1) Search agents, their task is to retrieve the URLs containing user information, (2) Downloading agents, their task is to download the web pages of URLs retrieved by web access search agents, and finally (3) Filtering agents which will filter the required information from the down loaded web pages. Filtering will require domain specific vocabulary or ontology.
Once the profile-building agent obtains all the filtered information it will intelligently modify the stereotype to build the final profile. This profile is then passed on to Mission manager for mission generation. 3.3 Mission Generator Mission Generator is the module whose responsibility is to create a mission based on the user profile and request. For an agent to autonomously perform tasks on behalf of a user, it must have a mission. Hence, a mission can be elaborated into a set of tasks that an agent must perform. If all the tasks specified are performed, it is concluded that it has achieved its mission. A mission in eHermes is represented as an attributed Direct Acyclic Graph (DAG). The ability to specify tasks dependencies (from any task to any task) and to break goals into sub-goals using this type of representation is regarded as very important for a software agent to understand its mission. We call this tree-structure a Task Decomposition Diagram (TDD). Our task decomposition diagram is similar to TÆMS’ [10] Task Tree Structure but it is simpler in that ours does not contain functions such as Quality Accumulation Functions (QAF) and local/non-local effects (enables, precedes, facilitates, hinders, uses and limits), however, ours is adequate for our purposes. The visual structure of our TDD is presented in Figure 4. A
B
C
D
C o m p o u n d T a sk
E
F
G
H
I
P r im iti v e T a s k D e p e n d e n c y L in k
J
K
L
M
F ig u r e 4 : T a s k D e c o m p o s itio n D i a g r a m ( T D D )
Each node in TDD represents a task. There are two types of tasks in TDD, namely: compound and primitive tasks. A primitive task is defined as a basic action that an agent can perform, and hence this type of task cannot be decomposed further. A compound task however, is a task that comprises a combination of one or many other compound or primitive tasks. Tasks A, B, C, D, I, J and K in Figure 4 are regarded as compound tasks while tasks E, F, G, H, L and M are primitive tasks. The task that has 0 indegree (i.e. task A in Figure 4) is regarded as the goal of the mission. Task A is said to be completed if and only if tasks B, C and D completely are. In turn, task B is completed if task E, F and G are completed. There are two types of arrows in TDD, they are: decomposition and dependency arrows/links. Decomposition links are depicted as solid arrows in Figure 4, while dashed-arrows are used to illustrate dependency links. Decomposition links are used to represent the hierarchical structure of tasks, while dependency links are used to represent the “dependency” relationship between tasks. From Figure 4, tasks E, F
and G are produced by decomposing task B. Furthermore, task I depends on B and task D depends on task C. Task dependencies are important aspects that have to be captured in a mission because they represent real-world situations. For instance, a human robot that was asked to reverse a car would put the gear into reverse mode first before slowly releasing the clutch pad and pressing the accelerator pad gently. Subsequently, it will not put the gear into reverse mode until the clutch pad has been pressed.2 Mission Generator uses traditional partial-order and hierarchical planning algorithms to produce TDD. Presentation of those algorithms is outside the scope of this paper and hence is skipped. However, interested readers can refer to [11] for good discussions about them. 3.4
Agent Generator
Agent generator is a component that is in charge of creating agents within eHermes. In creating agents (either stationary or mobile), the agent generator uses the ontology repository to get appropriate domain knowledge. Furthermore, reusable agent components will be used from the Agent Component Library. Once the task decomposition diagram (that is the mission itself) has been created, it is then passed onto the agent generator. Upon receiving this mission, the agent generator will create a special agent called Mission Control Agent. Mission Control Agent (MCA) is considered to be a special type of agent because it has the following properties: 1. Coordination: it coordinates, monitors and manages the execution of a mission, ensuring the final goal is reached, and 2. Intelligence: it has some built-in knowledge about how to optimize the execution of a mission by recognizing the dependencies between tasks and executes those that are not depending on each other in parallel. MCA, through its whole life cycle has a managerial role. It coordinates and oversees the execution of a given task. If necessary, when a mission cannot be completed due to an undo-able task(s), MCA will report to the actor about the situation. Depending on the actor’s response, MCA may continue the mission, abort or let the actor redefine the mission. MCA needs worker agents to perform tasks. These worker agents, which normally are mobile agents, have to be created on the fly and on a mission-to-mission basis. MCA does not have the ability to create such agents and hence relies on the agent generator to do so for it. To get the agent generator to create the agents it needs, MCA must supply a specification about the agents it wants to the generator. This specification includes an itinerary for the created agent (if necessary), the task to do once it has reached the destination and how to send the results back to MCA.
2 It is assumed that the robot is using a manual car in this context.
3.5
Ontology
As shown in Figure 2, one will notice that we have adopted the use of Ontologies. It is not possible to access heterogeneous databases without the need for concepts to be explicitly defined and for the concepts to be shared by the sites. It is expected that each site may use varying terms for the same concept - through ontology the terms will resolve to its common semantic meaning. In eHermes we are envisioning the use of several types of ontologies. We foresee at least of course the need for a domain ontology. However we foresee that there will be a need for some ontologies that support the infrastructure process mechanism which are non-domain specific. We outline below the tentative approach we are undertaking. 1. Domain Ontology. Domain ontology is by default necessary so as our mobile agent can roam freely and visit sites that house domain-specific information. Knowing these sites do not necessarily share common terms but of course share our concepts, the use of ontologies is expected to help us overcome the problem of interrogating non-alike databases. The challenge for us is to accommodate any proposed existing ontologies that deal with domain-specific needs. As an example, the IEEE Standard Upper Ontology Working Group has developed a financial ontology found in http://ontology.teknowledge.com. The adequacy of the ontology for our application needs further investigation. 2. Infrastructure Ontology. Here we envision the use of several auxiliary ontologies, these are ontologies that do not deal with a domain but it deals with concepts that help the operation of eHermes, as for example like that found in [12]. 3.6 Filter/Presentation Filter/Presentation module is actual module that performs content adaptation based on the QoS and profiles. This module accepts an input from an MCA, which sends it a tuple that contains the result of the mission in row format, user profile and device profile. Based on the user profile, this module will format the result into a form that the user likes. For instance, if the user likes blue colour then the result will be presented in a form that has a lot of blue colour. Based on the device profile, this module also understands about the device capability. However, eHermes also uses reconnaissance agents to collect crucial information such as the round-trip time, the network in which the user is now in and the properties of this network. eHermes needs to do this because there is a possibility that the user has changed network coverage from the time he sent the request to the time where eHermes is ready to send the data. Based on this collective data, this module will then adapt the content to the format that the device can present best within the network capacity constraint.
4
A Sample Scenario
This section shows a sample scenario of a request being made to eHermes from a mobile device. It is assumed here that the device is not within a wireless LAN but WAN with a poor data throughput. Consider Figure 5 below. 2 M
1 Request, DeviceID M
4
eHermes
RA
M
3
M
5 QoS 6 Filtered Results
Figure 5: Usage scenario
The interaction sequence of Figure 5 above can be illustrated as follow: 1. From the eHermes client program that resides in the mobile device, a user sends a request to eHermes. Along with this request, information about the device is also sent. 2. eHermes receives the request, perform some internal tasks such as building the profile, formulating the mission and then executing the mission. During this execution, the MCA creates a number of mobile agents with specific tasks according to the mission. 3. Those mobile agents come back to eHermes once they have completed the task assigned to them; bringing back the result to them. 4. A reconnaissance agent (RA) is sent prior to sending back the results to the user. 5. RA comes back to the system along with information about the network’s QoS. This information along with user’s profile will be used by eHermes to format the result (content) into the most appropriate format. 6. The final result is sent to the user.
5
Conclusion and Future Work
We have outlined in this paper how eHermes can be used to provide information gathering and adaptation services to mobile device end-users over wireless networks. The agents are generated, deployed, and coordinated by the system without too much user effort. Specific features which we have designed into eHermes to increase its generality to support a wide range of applications is the ability to instantiate a domain ontology at run-time, and to generate agents on-demand as needed by the application (assuming an adequate ontology database and agent component library). Dynamic characteristics and diversity of the wireless environment (of network and device) and cost-efficient concerns motivate our use of mobile agents and the use of reconnaissance agents. To deal with a diversity of users and alleviate the burden of usage, eHermes manages profile information and also employs agents to unobtrusively find information about users when required. We are working on a prototype of the system. eHermes will be using GPGP (Generalized Partial Global
Planning) for agent coordination. More information about GPGP, including its formal definition and experimental methodology can be found in [13].
Acknowledgements Support for this project from the Australian Research Council (ARC) Linkage Grant LPO211384 is thankfully acknowledged.
References 1. Laamanen, H. and S. Campadello. Software Agent Technology in Nomadic Computing: FIPA Nomadic Application Support. in International Symposium on Services and Local accesS (ISSLS 2002). 2002. Seoul, Korea. 2. Bellavista, P., A. Corradi, and C. Stefanelli, Mobile Agent Middleware for Mobile Computing, in Computer. 2001. p. 73-81. 3. Loke, S.W., An Overview of Mobile Agent Technology for Distributed Applications: Possibilities for Future Enterprise Systems. Informatica: An International Journal of Computing and Informatics, 2001. 25(2): p. 247-260. 4. Yang, J., H. Seo, and J. Choi. MORPHEUS: A More Scalable Comparison-Shopping Agent. in Proceedings of the Fifth International Conference on Autonomous Agents. 2001. Montreal, Quebec, Canada: ACM Press. 5. Dutta, P.S., S. Debnath, and S. Sen. A Shopper's Assistant. in Proceedings of the Fifth International Conference on Autonomous Agents. 2001. Montreal, Quebec, Canada: ACM Press. 6. Dasgupta, P., et al., MAgNET: Mobile Agents for Networked Electronic Trading. IEEE Transactions on Knowledge and Data Engineering, Special Issue on Web Applications, 1999. 7. Bayardo Jr, R.J., et al., InfoSleuth: Agent-Based Semantic Integration of Information in Open and Dynamic environments, in Reading in Agents, M.N. Huhns and M.P. Singh, Editors. 1998, Morgan Kaufmann Publishers, Inc.: San Francisco. p. 205-216. 8. PalmSource, Wireless Enterprise Applications for Mobile Information Management, www.palmos.com/dev/tech/webclipping/wireless.pdf. 9. Rich, E., Stereotypes and user modeling. In: A.Kobsa, and W.Wahlster (eds.), User Models in Dialog Systems. Springer-Verlag, Berlin, Heidelberg,, 1989: p. 35 - 51. 10. Decker, K.S., TÆMS: A Framework for Environment Centered Analysis & Design of Coordination Mechanisms, in Foundations of Distributed Artificial Intelligence, N.R. Jennings, Editor. 1996, John Willey & Sons. p. 429-447. 11. Russell, S.J. and P. Norvig, Artificial Intelligence: A Modern Approach. 1995: Prentice Hall. 12. Cranefield, S., et al. Ontologies for Interaction Protocols. in Proceedings of AAMAS02, Workshop on Ontologies in Agent Systems. 2002. Bologna, Italy. 13. Decker, K.S. and V. Lesser. Designing a family of coordination algorithms. in The 1st International Conference on Multi-Agent Systems (ICMAS-95). 1995. Seattle, WA: AAAI Press.
