Design and Implementation of An Agent-based Middleware for ...

Design and Implementation of An Agent-based Middleware for Context-aware Ubiquitous Services Hideyuki Takahashi




, Yoshikazu Tokairin , Takuo Suganuma , and Norio Shiratori Research Institute of Electrical Communication Graduate School of Information Sciences, Tohoku University

Abstract. In ubiquitous computing environment, different kinds of system components including hardware elements, software components and network connections are required to cooperate with each other to provide services that fulfill user requirements. This paper proposes an agent-based middleware for ubiquitous environment that consists of computers and home electric appliances. The middleware, called AMUSE, can take QoS (quality of service) in ubiquitous environment into consideration by coping with not only user context but also resource context, using agent-based computing technology. In this paper we describe concept, design and initial implementation of AMUSE. Simulation results of experimental ubiquitous service using AMUSE has been shown to prove the effectiveness of our proposed scheme. Additionally, we show the initial implementation of multimedia communication application based on AMUSE to confirm the feasibility and effectiveness of our scheme. Keywords. Ubiquitous Computing, Agent, Context-aware, QoS, Service construction

1. Introduction In recent years, researches on ubiquitous computing [1] environment and service provisioning on the environment has been greatly accelerated. There are two mainstreams in researches on ubiquitous services; one is research on user context in the environment, and the other is for service construction scheme. In user context researches, advanced methods for obtaining user’s physical location and finding appropriate services from the locating information and user profile are mainly investigated [2]. On the other hand, in researches on service construction, superior frameworks and schemes are actively challenged for dynamic cooperation among many kinds of system components, i.e., entities in ubiquitous environment, to provide user-oriented services [3,4,5,6,7,8]. The discussion on actual applications of ubiquitous services have been mainly focused on remote control of home electronics appliances from portable devices and information delivery system based on user’s locating information. In the future, user de1 Hideyuki Takahashi, 2-1-1 Katahira, Aoba-ku, Sendai 980-8577, JAPAN. Tel.: +81(22)217-5454; Fax: +81(22)217-5411; E-mail: [email protected].

F A X

D e s k to p P C

C e l l -p h o n e

S p e a k e r

TV

L a p to p P C

User

P D A

C e l l -p h o n e

H e a d s e t

User

P D A

M ic r o p h o n e

Room C

Room A D ig ita l C a m e ra

C e l l -p h o n e

User

P D A

Room B

Fig. 1. An application of ubiquitous service provided by multimedia home electric appliances.

mands on these ubiquitous services will move into much richer applications such as multimedia communication services. Thus, we are promoting research and development on fundamental technologies aiming at post ubiquitous computing environment, including multimedia service provisioning by cooperative behavior of audio-visual home electronics appliances. For instance, we are targeting at the services such as video streaming or videoconferencing constructed from coordination of computers and home appliances as shown in Fig.1. To provide necessary and sufficient QoS that satisfies user requirement is an intrinsic problem to realize such ubiquitous services. To address this, we have to consider not only from user context, but also resource context of hardware, network and software. This is because resource availability tends to be poor and unstable in ubiquitous environment. In addition, multiple users would be given the ubiquitous services simultaneously, thus problems of effective resource sharing and assignment should be addressed. In this research, we are aiming at investigating ubiquitous service construction scheme in order to provide QoS-aware and stable services against changes of resource status and user’s situation. We proposed an unique idea of effective handling of multiple contexts including user context and resource contexts. To accomplish the objective, we apply agent-based middleware approach. The remarkable feature of this approach is agentification of each entity in overall ubiquitous environment. We embed context management ability and cooperation ability for conflict resolution on multiple contexts to each agent. Furthermore, we give maintenance mechanism for long-term context to accumulate and reuse history and experiences of past cooperation among agents. The individual behavior and the cooperative behavior of agents would make the QoS-aware service provisioning possible. The primary contribution of our work is that it enables provisioning rich services such as multimedia communication services in anytime and at anyplace with comfortable quality. In this paper, we propose a multiagent-based middleware for ubiquitous computing environment, called AMUSE (Agent-based Middleware for Ubiquitous Service Environment). Moreover, we describe design of AMUSE focusing on the service construction scheme for QoS-aware service provisioning considering the multiple contexts. We evaluate our proposal from results of simulation experiments. Furthermore, we illustrate the

initial implementation of multimedia communication application based on AMUSE to confirm the feasibility and effectiveness of our scheme. The rest of this paper is organized as follows. In Section 2 we present the motivation and concept of AMUSE. In Section 3 service construction scheme in AMUSE is described. The simulation results are presented in Section 4. Moreover an application of AMUSE is illustrated in Section 5. Finally we conclude this paper in Section 6.

2. Concept of AMUSE 2.1. Related Work Our work on the context-aware middleware is related to many other researches in this field. CARMAN [2] considers Mobile News Service(MNS) for mobile users. It provides service based on user mobility, device’s performance and user’s preference. When the service is provided by a single mobile device, performance of the device is most important for the service. Therefore there are various kinds of works for providing high quality of web service within the limits of device’s performance [9]. These works are focusing on provisioning individual user-centric service using a single mobile device. To provide multimedia service by utilizing the available resources, we found it will be more efficient if multiple devices around the user can be used at the same time, instead of using only a single mobile device. In other similar works, service is provided by coordination with any devices around user. For example, there are frameworks like STONE [6] and Ninja [8]. These frameworks construct the service based on service template which is requested by user. It means they search appropriate function to the requests and cooperation between various devices. In addition, Ja-Net [3] focuses on emergent service based on user preference. The purpose of these works is same as our proposed work in terms of providing the service by coordination with heterogeneous entities. Moreover these works are providing superior mechanism of useful naming system, service description language, and service emergence. However, we suppose existing service construction schemes are based only on user context and functional components, and they are concentrating on guaranty of coordination and operation or standardization of the specifications. Because it is important for ubiquitous environment to satisfy a particular requirement and limitation including network and computer resources. In case of rich service provisioning such as multimedia communication services in ubiquitous environment, we suppose it is much more important to consider QoS. For instance, there are ever-changing situations like user mobility, device’s performance around user, and resource condition. Therefore, there would be a possibility that devices that are physically very close to the user can’t provide the service due to lack of the resources, even if the devices potentially have good performance. Moreover it’s necessary to provide the service considering cooperation problem of unexpected devices, softwares, and network. From analysis of these previous works, we concluded that it’s required to achieve service construction scheme which considers not only user context but also other contexts, in effective and integrated manners.

2.2. Target issues Following three technical issues need to be addressed to provide QoS-aware services on ubiquitous computing environment that consists of computers and audio-visual home electric appliances. (P1) Resource context maintenance  Here we define “context” as situation of target entity at time and temporal changes  of the situation after/before time . The situation of target entity is represented as internal representation model of the entity. Previous works for context awareness have been mainly focusing on user context acquisition scheme including locating information of the user. However, in terms of resource of entity, it was treated as only a value of the target  resource parameter at time , not as “context”. In ubiquitous environment that consists of many kinds of entities in different level of functionality and performance, it is important to consider resource context efficiently as well for proper QoS control. (P2) Multiple context coordination In ubiquitous environment on which heterogeneous entities coexist, QoS should be maintained in the range from entity level to overall system level. To do so, we have to consider not only input/output specification of the entity, but also multiple context coordination including user context and resource context. (P3) Non-deterministic property of service construction Furthermore we need to cope with problem of mutual dependency and interoperability among entities that are not resolved deterministically from analysis of static specifications of entities. This is because each entity is basically designed to work by itself, not designed to work with other entities cooperatively. Thus, services constructed from the entities would not work properly in accordance with the specifications. 2.3. AMUSE framework In AMUSE, we solve the technical issues P1 to P3 described in the previous section with the following two approaches. (R1) Agentification of each entity “Agentification” is a process to make a target entity workable as an agent by adding knowledge processing mechanism to the entity. In our proposal, we agentify each entity respectively. Also we add context management ability and cooperation ability to resolve context conflict to the agents. Moreover, we embed long-term-context maintenance ability to the agents to accumulate cooperation history and experiences. Thus we can overcome the issues related to P1. (R2) Multi-context-based Service Construction scheme To realize QoS-aware ubiquitous service construction considering multiple context, we propose contract-based service construction scheme of agents, to solve the problem of P2. Agents make organization based on CNP (Contract Net Protocol [10]). Moreover, we model heuristics and dependency information on cooperation history in past among agents as long-term context among agents. This kind of context is also managed by the agent. By using this context, agents can construct more advanced services employing lessons learned. This would be a solution to P3. The fundamental framework of AMUSE is shown in Fig.2. AMUSE consists of four layers, i.e., Primitive Agent layer (PA), Agent Relationship layer (AR), Agent Organiza-

U b iq u ito u s S ervic e(U S )

Agent O rga niz a tio n(AO )

Agent R el a tio ns h ip (AR ) S oftw ar e agents

N etw or k agents

U ser agents

H ar d w ar e agents

Primitive Agent(PA) Agentification of entities S oftw ar e com p onents

N etw or k connections

U ser s

H ar d w ar e el em ents

Ph y s ic a l E ntity

Fig. 2. Framewrok of AMUSE

tion layer (AO), and Ubiquitous Service layer (US), based on concept of symbiotic computing [11]. PA makes physical entities to agents. In PA, context of each entity is managed by corresponding agent. In AR, inter-agent relationship based on long-term context among agents is created and maintained. In AO, agent organization is constructed based on the context in PA and AR, when user requirement to specific service is issued. On the top layer US, actual ubiquitous service is provided to users. 2.4. Service provisioning process in AMUSE Service provisioning process in AMUSE framework is shown in Fig.3. This process consists of the following six steps. (1) Entity agentification Each entity is rebuilt as agent by adding domain oriented knowledge representation model that is suitable for classification of the entity. Details of agentification mechanism are illustrated in Section 2.5. (2) IAR updating We define long-term context among agents as Inter-agent Relationship (IAR). Each agent has different IARs to all other agents with which it has cooperated in past time. Each agent updates their IAR after its service provisioning by itself or by cooperation with other agents. More details of IAR are described in Section 3.2. (3) User requirement acquisition Agent acquires user requirement, and analyzes the requirement from user’s profile, locating information, and behavior in the ubiquitous environment. Agent has to choose in the most suitable manner to get the requirement, because useful input devices may not be available in everywhere. This remains an open problem and is not treated in this paper.

(1 ) E ntity agentif ication (2) IA R

updating

(3 ) U ser req uirem ent acq uisition

(4)Service construction and (5) Service provisioning (6 ) U ser eval uation Processes focused on this paper

Fig. 3. Service provisioning process based on AMUSE framework

(4) Service construction and (5) Service provisioning After user requirement is acquired, agents construct its organization using CNP to provide service. In this scheme, we apply hierarchical CNP, i.e., task announcement is propagated in order of hardware agents, software agents and network agents. The agent organization is created based on context managed by each agent, and actual service is constructed and provided with combination of entities controlled by agents. Details are discussed in Section 3. (6) User evaluation When the service provisioning is finished, the agent organization receives user’s feedback concerning the quality of provided service. To measure the evaluation, we introduce us-effectivity(  ) referring Ja-Net [3]. In AMUSE, when  value changes, each agent informs the update to all other agents that have relationship to it. That is, the evaluation result is propagated to all related agents, and it effects to service construction subsequently. Details are illustrated in Section 3.3. 2.5. Agent architecture for AMUSE The basic architecture of agent in AMUSE is shown in Fig.4. Here Cooperation Mechanism (CM) is a mechanism for exchanging messages among agents. Domain Knowledge (DK) is a knowledge-base system to store and activate various domain knowledge concerning the target entity. Based on the knowledge, agent monitors and controls the target entity, and makes actions to other agents. Entity Processing Mechanism (EPM) is an interface between DK and target entity. It passes events from entity to DK such as exceptions, and directs control instruction from DK to entity. DK consists of three subsystems, i.e., Working Memory, Inference Engine and Rule Base. In Working Memory and Rule Base, set of Facts and Rules are stored respectively. Inference Engine refers to the Rules and Facts, and works as production system. By

Agent Communication Language Coop er ation M ech anis m D K

W or k ing M emor y

I nf er ence E ngine

R ul e B as e

E ntity P r oces s ing M ech anis m E ntity Agent Fig. 4. Basic agent architecture

employing this inference mechanism, agent performs interaction with other agents and controls the target entity. Fig.5 shows management functions for service construction in AMUSE. These functions are implemented as Rule set and related Facts in DK. IAR Management is module for maintenance of IAR such as creating, updating and deleting of it. Context Management is module for monitoring and recognizing context of the entity. Moreover Contract Management is module to maintenance contract conditions and contract status in case that contract relation is created with other agents. 3. Service construction scheme in AMUSE 3.1. Creation of IAR IAR consists of three kinds of relationships. They are, Tight-Relationship (TR), GroupRelationship (GR) and Competing-Relationship (CR) like shown in Fig.6. (a)Tight-Relationship(TR) TR is created among agents that provide some services by constructing organization of the agents. By using this relationship, it is possible for the agent to have past cases of successes and failures in cooperation. (b)Group-Relationship(GR) GR is given to group of agents that have some potential dependencies. For instance, there is GR among hardware entities such as desktop PC, speakers and PC displays. By using GR, it is possible that agent informs changes in their states frequently to the agents within the group.

D K

W ork i ng Memory

R u l e B as e

Contract Management I A R Management Contex t Management

I nf erence E ngi ne

Fig. 5. Management modules in DK for AMUSE

(c)Competing-Relationship(CR) CR is formed among agents that have same function. Why this relationship is introduced is that these agents would compete when task announcement of the function is issued. By using CR, the competing agents routinely inform their status to each other, and they can make good organization effectively when CNP-based negotiation runs. 3.2. Knowledge representation of IAR Fig.7 shows knowledge representation of IAR. IAR is represented in set of iar which is an individual relation. The iar consists of id, name, func, relationship, state, availability, and shared values. The id is an integer value to identify each agent. The name is a name of agent against which the iar points. The func is an expression of functionality of the entity such as specification of I/O. It is a set of type. The type represents each function. For instance, the agent that has I/O function of the voice has audio-output and audio-input in type variable. The relationship indicates type of relationship such as TR, GR and CR. The state indicates present state of agent. Here, running means state of service is being provided, online means state of standby, and offline means state of service cannot be provided, respectively. The availability indicates degree of effectiveness of the agent. It consists of acceptability, us-effectivity, etc. The acceptability ( ) indicates acceptance ratio to task announcement or bid of the agent.   

(or    )  Here,  is number of times that agent has been received bid, is number of times that agent has sent task,  is number of times that agent has been received award and  is number of times that agent has sent bid. The us-effectivity ( ) indicates metrics of evaluation that agent receives after providing user with service.  




A g ent o f th e sa m e f u nctio n

U

C o m peting -R el a tio nsh ip

User Agent

U

C rea tio n o f rel a tio nsh ip

U

U

C o o pera tive service

T ig h t-R el a tio nsh ip

U

U

E ntities w ith po tentia l dependency

U

T ight-Relationship C om m u nic ation

G ro u p-R el a tio nsh ip

U

Independent service

G rou p-Relationship C om m u nic ation

C om peting-Relationship C om m u nic ation

Fig. 6. Creation of Inter-Agent Relationship

IAR ::= {iar} * iar ::= < id, nam e, f unc , relationship, state, availability, shared values > id ::= int nam e ::= string f unc ::= {type} * type ::= audio-output | audio-input | im ag e-output | im ag e-input | … relationship ::= T R | G R | C R state ::= running | online | of f line availability ::= < ac c eptability, us-ef f ec tivity, … > shared values ::= < operating rate, …> Fig. 7. Knowledge representation of IAR

Here,  is the total number of times of good evaluation, and  is the total number of times of good and bad evaluation based on strength value of Ja-Net [3]. The initial values of  ,  and  are set to 1. The shared values is referred as common index used by each agent. For instance, there is operating rate (  ) that indicates how often agent is usually used.  

Here,  is number of times in which it is used. The  is fixed period which is decided by user. It can be used to understand trend of changes in the preference of the user according to the shared values.

3.3. CNP-based service construction with IAR Our scheme which is based on CNP builds agent organization using three kinds relationship. CNP is a mechanism to make contract relationship among agents by exchanging messages such as task announcement, bid, and award, shown in Fig.8. Here, we explain features of service construction scheme with IAR. (1)Case of Tight-Relationship(TR) In Fig.8(1), we assume that agent A has a relationship of type TR with both agent B and agent C whereas no relationship exists between B and C. TR between A and B indicates that trouble was occurred when they had cooperation in the past, and TR between A and C indicates no trouble in the past. When B and C receives the task announcement from A, they refer to each IAR. Here, B does not send bid because TR against A is bad. That means the trouble in cooperation would occur this time too. On the other hand, C sends bid because C judges from TR that it would contribute to the task announced. In fact, it is possible to reduce trouble in cooperation by agent considering coordinated relationship in the past. (2)Case of Group-Relationship(GR) In Fig.8(2), we assume that agent A has no relationship with both agent B and agent C whereas relationship of type GR exists between B and C. Here, C recognizes that GR against B exists when C judges the task announcement from A. Then C sends bid if C judges that B can provide service by referring to state in IAR. On the other hand, C ignores the task announcement if B can not provide service. In fact, it is possible to reduce the trouble in cooperation by agent considering dependency of the agents. (3)Case of Competing-Relationship(CR) In Fig.8(3), we assume that relationship of type CR exists between agent B and agent C whereas agent A has no relationship with both B and C. B and C receive the task announcement. Each agent checks IAR of type CR if it can process the task. When agent has CR, it refers to state of the CR. For instance, B sends bid in case that B judged the value of us-effectivity on this task is higher than that of C. On the other hand, C ignores the task announcement in case that it judged us-effectivity of B is higher than C. In fact, it is possible to efficient construction of service by consideration of state of same function agent.

4. Simulation and evaluation 4.1. Implementation We implemented agents based on AMUSE to perform simulation. In the implementation, we employed agent-based programing environment DASH [12] that is based on multiagent programing framework ADIPS [13]. We also performed simulation by IDEA [14]. IDEA is interactive design environment for Agent system. We used DASH programing environment because agent which is developed for simulation can easily be reused when we build the real-world system in future.

< CN P c on si d er i n g I A R> M a n a g e r A g e n t

H a rd w a re A g e n ts S o ftw a re A g e n ts

N e tw o rk A g e n ts b id

ta s k

a w a rd

T R

G R CR

(1) Case of TR

A

1 . t as k

2 . b id

B

C iar : n am e A : re l at io n s h ip TR

iar : n am e A : re l at io n s h ip TR :T R

:T R

b a d

(2 ) Case of G R

B

A

2 . b id

1 . t as k

C

s t at e : o n l i n e

b id

B

A




u s -e f f e c t iv it y : 0 . 5

iar : n am e C : re l at io n s h ip C R : u s -e f f e c t iv it y 0 . 1

s t at e : o n l i n e

iar : n am e B : re l at io n s h ip G R : s t at e o n l i n e

iar : n am e C : re l at io n s h ip G R : s t at e o n l in e

(3 ) Case of CR

n u ll

C

u s -e f f e c t iv it y : 0 . 1

iar : n am e B : re l at io n s h ip C R : u s -e f f e c t iv it y 0 . 5

Fig. 8. Characteristic of CNP by IAR

4.2. Evaluation method We performed simulation of system behavior based on AMUSE. In this simulation, QoS awareness of the system is measured and we investigate how much the QoS awareness is improved by introducing AMUSE. To measure the QoS awareness, we apply User Request Achievement ( !! ) level. Using these metrics, we can measure how much the user requirement is fulfilled with provided quality of service by the system. Details of "# are described later. Fig.9 shows the behavioral situation representation of the system. Here, three entities including a hardware entity, a software entity and a network entity are making organization and providing service to a User. The user issues “User Request QoS” and the system provides service with “Provided QoS”. Hardware Agent (HA) monitors CPU resource context and Network Agent (NA) monitors bandwidth resource context. On the other hand, Software Agent (SA) has knowledge concerning mapping from resource availability onto actual user level QoS. The QoS evaluation of service is based on !! . !! is calculated by comparison between User Request QoS $ and Provided QoS %'& . We defined the range of !! is from -1 to 1. Here, () is an element of $ and it represents User Request QoS on service element * . Also +, ) is an element of %-& and it represents Provided QoS on service element * . The value of () and +,) is from 1 to 10. Here, !! on service element * , i.e. "#.) is represented as follows: % &01 +2, 3 +,4 35657568 ' $91:(  3 ( 4 3257575;8 "#.)=@?BA@@CEH DGF:A User

Provided QoS

/

/

/

U ser Request Q o S H a rd w a re

S o f t w a re

A g en t K n o w l ed g e C P U

Reso ur c e C o n tex t

H a rd w a re A g en t

S o f tw a r e Reso ur c e C o n tex t S o f t w a re A g en t

N et w o rk

B a n d w i d th Reso ur c e C o n tex t N et w o rk A g en t

S y stem Fig. 9. Behavioral situation representation of the system

This means that, if !!.) is above zero, the user requirement is fulfilled and if it is below zero, the requirement is not satisfied. In this evaluation, the number of service elements is assumed to be two (*!I 3  ) and !! indicates the total !! , that is, a mean value of !!  and !! 4 for simplification. We performed simulation of service construction with the above conditions for 500 times. The agent constructs CR immediately after simulation beginning. When SA constructs service, it refers to NA’s bid and IAR. If SA judges that other agent is suitable, it disregards the task even if the task is acceptable. And if agent receives bid by two or more agents that can fulfill user requirement, agent sends award to agent with the highest value of  of IAR after referring to the value of  . In the actual simulation, we use only the strength of Ja-Net for the value of  . The simulation receives a assumed user evaluation each time of service construction. The user evaluation is reflected to  . User evaluation is assumed good if +, ) is within from 120% to 100% when (: ) is regarded as 100%. In this case value  is set to 1. It is assumed bad in case that +,J) exceeds 120% or is below 80%, and the value is set to -1. Otherwise it is regarded as usual, and the value is set to 0. We compare three patterns of agent behaviors, i.e., our proposal (IAR-based approach), the case considering only user context (User-request approach), and the case considering only the maximum QoS value of agent for QoS without consideration of resource context (Maximum approach). For the simulation, resources of HA and NA are assigned random values in every service construction. Also we give tendencies of user request in three patterns, which is high quality (7 K 10), middle quality (4 K 7), and low quality (1 K 4). 4.3. Simulation results and evaluation Fig.10K Fig.12 shows the variation of the value of "# . Fig.10 is a comparison where $ is always in high, Fig.11 shows the comparison where $ is always in middle, and Fig.12 depicts the case where $ is always in low. Fig.13 K Fig.15 shows the frequency distribution concerning !! . Fig.13 is a comparison for case that $ is always in high, Fig.14 is a comparison for case that " is always in middle, and Fig.15 is a comparison in case that $ is always in low. From analysis of Fig.13 in case that $ is always in high, our approach could achieve the user requirement with higher frequency than User-request approaches. From this result, in case that user requirement is higher than the service environment, it can be understood that the requirement can not be fulfilled even if only user context is considered. Moreover, in case that agent considers only the user request and the maximum value that can be selected, !! generally is lower than our approach, when user requirement is not fulfilled. It is understood that some conflict on resource context is occurred. Also it is understood that our approach decreases bad service construction by considering IAR. This is because that IAR decreases the conflict of resource context. From these results our approach is rather effective in this kind of case. From analysis of Fig.14 in case that $ is always in middle, !! of User-request approach often closes to zero much more times than other approaches. On the other hand, compare to the User-request approach, IAR-based approach could fulfill the user requirement frequently. Moreover the case that !! of our approach is higher than






     
!                  "   
                   
 
 
 
 
                             Fig. 10. Variation of value of LNM