Mobile Agents for Service Personalization in
Smart Environments
Ivan Marsa-Maestre, Miguel A. Lopez-Carmona, Juan R. Velasco, and Andres Navarro
Departamento de Automatica, Universidad de Alcala, SPAIN {ivmarsa,miguellop,juanra,andres}@aut.uah.es
Abstract—Service personalization is an important goal for any smart environment. Comfort systems may be adjusted in an automatic way when a given user is present, and multimedia devices may offer a music or movie catalog with favorite contents or may even pick one of them for the user. To achieve this goal, we propose a Service Oriented Architecture implementation based on multiagent systems. We specially take advantage of the mobility features of soft-ware agents. In particular, we have developed a hierarchical, agent-based solution intended to be applicable to different smart space scenarios, ranging from small environments, like smart homes or smart offices, to large smart spaces like cities. In this paper we describe the global architecture and focus on our approach to service personalization using mobile agents that follow the users as they move through different smart spaces.
Index Terms—Mobile agents, Service oriented architec-tures, Smart spaces
I. INTRODUCTION
Environments we interact with on a day-by-day basis, like our home, our car, or our office, tend to offer us a continuously increasing comfort level. New technologies allow us to communicate in ways we could not have foreseen ten years ago. The world is going digital, even in fields that were analog by nature, such as music, films, television or photography.
At the same time, the number of electronic devices per square mile is growing endlessly. But this does not necessarily mean our lives are better and simpler. We can access more services, but we trade availability for ease of use. For example, the number of remote controls at home grows according to the number of electronic devices, so users need to learn to use new interfaces whenever they add a service to their home.
In this context, systems which strive for environment personalization appear. These systems are intended to release users from the routine tasks they should perform otherwise to change their environment to suit their pref-erences and to access the available services. The goal we seek is a smart environment, able to adapt itself to the user needs and to provide customized interfaces to the services available at each moment. To achieve this goal, we use multi-agent systems, as they have been revealed
Based on "Mobile Personal Agents for Smart Spaces", by Ivan Marsa-Maestre, Miguel A. Lopez, Juan R. Velasco, and Andres Navarro which appeared in the Proceedings of the IEEE International Conference on Pervasive Services (ICPS 2006), Lyon, France, June 2006 © 2006 IEEE.
as a good technology for the development of distributed, autonomous, and intelligent systems.
In our previous work [1] we designed and implemented an agent-based software architecture for smart homes. We are now extending this architecture to make it applicable to other environments as well. In particular, we have developed a hierarchical, modular architecture, which we call SETH (Smart EnvironmenT Hierarchy). The archi-tecture can be deployed in layers, which allows to create complex smart environments by combining, for instance, a certain number of smart rooms to create a smart building and a certain number of smart buildings and smart outdoor spaces to create a smart city.
We approach the problem of service personalization in smart environments by using personal agents and service agents as intermediaries between the users and the environment. Personal agents are responsible of learning and enforcing user preferences. To make this possible, personal agents need to be contacted whenever their as-sociated users request a service, or whenever a service of potential interest to the users becomes active. This implies the interchange of a significant volume of information between the personal agents and the system, which in turn results in a significant bandwidth consumption. The im-pact of this bandwidth consumption on the system overall performance may be lowered by making personal agents to be “closer” to service agents, taking advantage of fast LAN/WLAN communication channels. This is usually achieved by placing personal agents into mobile handheld devices, since most service access requests performed in smart environments are local to the physical space where the user is located. However, in large environments such as buildings or cities, there may be a significant number of users who either do not have handheld devices or do not carry them at a given moment. Furthermore, resource limitations in mobile devices make them prone to energy and bandwidth shortages which can lead to connectivity losses between the personal agents and the system. In these cases, relying on personal agents residing in hand-held devices is not enough. Service agents, on the other hand, are entitled to provide the services requested by the personal agents, and usually reside in the location where the service is provided. There are services, however, such as content access and unified messaging, which may be desired to be provided in a location-independent manner, or even required to follow the users as they move to
different locations. Taking this into account, we propose to take advantage of agent mobility for personal agents and service agents. Those agents move from one smart space to another when required, thus effectively following user movements throughout the entire environment.
The rest of this paper is organized as follows. Section II recalls the most relevant previous works our research is related to. Section III outlines our architecture for smart spaces and summarizes the different devices and software agents present in the system. Section IV briefly describes our strategy to context generation, interpretation, and discovery, which is paramount for our architecture. Sec-tion V presents our proposal of using mobile agents to provide on-site service personalization, both in the case of mobile personal agents and mobile service agents. Experimental results are analyzed in Section VI. The last section summarizes our main contributions and sheds light on some future research.
II. RELATED WORK
Our work is based on a number of previous findings from other authors on different fields like software agents, smart environments, context-aware systems, service ori-ented architectures and service personalization. In this chapter we provide a brief outline of each field, discussing both its objectives and the state of different research lines. A. Smart Environments and Software Agents
We can define a smart environment asone that is able to acquire and apply knowledge about its inhabitants and their surroundings in order to adapt to the inhabitants and meet the goals of comfort and efficiency [2]. These goals are normally directed to adapt the environment to the user preferences, to increase the performance of the user in his day-to-day tasks, and to optimize the energy consumption of the systems involved.
To meet these goals, a smart environment system is based on a set of devices which gather information about the environment -sensors- and a set of devices able to actuate over the environment to change its conditions -effectors-. The system will process the data collected by the sensors and, according to the predefined set of goals-, will use the effectors to alter the user environment. The key problem in domotics is how the system decides the necessary actions depending on the information provided by the sensors, as it requires analyzing data from several different sources distributed throughout the entire house, and coordinating equally heterogeneous effectors. These considerations lead to requirements of distributed data mining, autonomy and intelligence that suggest the use of software agents to develop this kind of system.
There are different definitions for software agents. From the viewpoint of design and technology, we can de-fine a software agent as a self-contained program capable of controlling its own decision making and acting, based on its perception of its environment, in pursuit of one or more objectives [3]. From a functional, user’s perspective, a software agent can be seen as a software entity to which tasks can be delegated. This last definition, though
simpler, suggests more clearly how this technology can serve the problem of intelligent automation of the envi-ronment. A multiagent system provides a distributed and flexible framework and communication and negotiation mechanisms among its components that allows them to make complex decisions in an effective and efficient way. B. Context-aware systems
One of the key features of smart spaces is their ability to adapt themselves to the preferences, desires and needs of their inhabitants. To achieve this ability, smart spaces must be able to acquire knowledge about the inhabitants and their surroundings. The information upon which this knowledge is built is called context [4]. Context informa-tion in smart environments is usually gathered through the use of heterogeneous sensors distributed throughout the entire space. Furthermore, information must be processed in real time, so that the systems may react to changes in the environment in a timely fashion.
Existing systems cover different domains such as tourist guides [5], indoor information systems [6], and smart environments [7]. These types of systems gather contex-tual information through sensors placed in the environ-ment, the information is reasoned, and actions are taken to automate features of the environment. Thereby it is necessary to make a decision before taking an action, and this requires an efficient context management. There are two ways to allow it [8]: context models and contextual ontologies. Context models provide access to contextual information similar to a database, whereas contextual ontologies represent knowledge about context.
C. Service Oriented Architectures
There is not an official and accepted definition for Service Oriented Architectures (SOA). We may say that a SOA is a paradigm for designing, developing, deploying and managing software systems that are able to offer ser-vices to other software systems. SOA does not specifically mean .NET, J2EE, CORBA, multiagent systems, ebXML or, the most extended, Web Services.
For [9], a SOA has the following attributes:
• Functionality is organized as a set of modular,
reusable shared services.
• Services have well defined interfaces and encapsulate
key business processes.
• Customer facing solutions serve as customized views
of these services for different segments, and can access these shared services as needed.
• The reusable shared services are built without
mak-ing any assumptions of who (portal or another ser-vice) will consume these services.
Main concepts that a SOA must present are [10]: Services:A service is a contractually defined behavior that can be implemented and provided by a component for use by another component.
Service descriptions: The service description consists of the technical parameters, constraints and policies that define the terms to invoke the service. Each service should include a service definition in a standardized format.
Advertising and discovery of services: A service must communicate its service description in an accessible man-ner to potential consumers. It does so by using one of several advertising methodologies, such as Pull and Push. In the Pull methodology, potential service consumers request the service provider to send them the service description. This pull methodology may be invoked as a service itself. In the Push methodology, the service provider, or its agent, sends the service description to potential service consumers. In any case, a Directory where service address may be found is needed.
Specification of associated data model:When invoking a service, certain parameters may be required to help the service to fulfill the service request. The service may also pass parameters back to the service consumer. To understand any required parameters serialization, an artifact is required to specify the associated data models for the services. Even if no parameters are used, SOA requires a base component to declare this in a format that is understandable to service consumers.
Pervasive service systems may greatly benefit from using a SOA paradigm. In this case, it is very important to define a deployment and management model for ser-vices, so a different team or company may develop every service. The complete system will grow in an incremental way as services are being included.
D. Service Personalization in Smart Spaces
There are vastly different lines of research regarding smart environments and service personalization. Our work is closely related to those involving potentially large environments such as workplace buildings and cities, those involving hierarchical arrangement of smart spaces, and those taking advantage of multiagent systems.
Cooltown [11] uses the technologies behind the Web to provide pervasive nomadic computing in urban envi-ronments. In Cooltown, interest places and resources are tagged with URLs or other identifiers that can be retrieved by users’ personal devices by means of bar codes, RFIDs or IR transceivers. URLs may be used to access the different services related to their associated points of interest, and other identifiers (such as ISBN codes) may be resolved to URLs which link to the services related to the identified item. Resources are grouped in places, and for each defined place there is a place manager, which maintains directories of resources, acting both as a resolver for looking up resources in that place from their identifier and as a Web server providing information about resources.
The Galaxy Service Model [12] is intended to provide a hierarchical service structure for a Smart Space Labora-tory. Galaxy uses a set of smart devices, which are called u-Textures and Smart Furniture. These devices may be aggregated to conform a Smart Space Laboratory. The Galaxy Service Model allows to export services provided by the different smart devices to create applications, which can be composed into other applications, resulting in a multi-layered service composition. Service discovery is performed hierarchically.
COBRA [13] takes advantage of multiagent systems to develop context-aware applications. It is based on a broker-centric architecture used to provide runtime support for context awareness in an Intelligent Meeting Room. In COBRA, the environment is divided in do-mains, and there is a broker for each domain, which is an autonomous agent that manages and controls the context model of the specific domain. Though COBRA brokers are intended mainly for context sharing, its centralized approach to management in each domain and the possi-bility of sharing context between domains through context federation is closely related to the approach we have taken in this work to develop our hierarchical architecture for smart spaces.
III. THESETH AGENTARCHITECTURE
The approach to service personalization proposed in this document is being deployed over our platform SETH (Smart EnvironmenT Hierarchy), which is an extension of the iHAP architecture we developed for smart homes [1]. Detailed description of the SETH architecture is beyond the scope of this paper, and can be found in [14]. In this section we outline the most relevant characteristics of the architecture as far as the work presented here is concerned.
A. A Hierarchy of Smart Spaces
Our architecture relies on the concept ofsmart spaces, which are specific, self-contained locations within the en-vironment. From a functional point of view, a givensmart space A is a tuple SMA= < DA, SA, CA >, where
DA ={da
i|i= 1...m} is a set of devices, SA={sai|i= 1...n} is a set of services, andCA ={ca
i|i= 1...l} is a set of beliefs representing thecontext information. Smart spaces may be indoor or outdoor spaces, and they may be also static or mobile -e.g. a smart car-.
Smart spaces may be hierarchically arranged if the specific characteristics of the environment require so. For example, in a smart office we may have a building smart space(SMbuilding), which may also contain severalfloor smart spaces (SMf loorx), each one containing several
smarts spaces related to deskrooms, corridors, elevators. . . This hierarchical approach allows us to provide different layers of services, context information, and security.
For clarification purposes, we will use throughout this article the following example scenario. We consider acity smart space(SMcity), which contains three indoor smart spaces,SMhome,SMrestaurant andSMworkplace, and an outdoor smart space SMmonument. This relationship is expressed as follows, where index1indicates the depth in the hierarchy tree:
SM{home,restaurant,workplace,monument}⊂1SMcity In the same way we describe the following relations:
SMsecondf loor ⊂1 SMworkplace SM{deskroom,presentationRoom} ⊂1 SMsecondF loor
Figure 1. Hierarchical arrangement of smart spaces in our application scenario
Finally, we also consider a mobile smart space SMcar. Figure 1 shows the hierarchy tree for the smart spaces in the described scenario.
Inheritance and aggregation rules may be established in the hierarchy to govern which context information, services and devices are available to a given user or agent at a specific location. Considering services, the set of available services SA in the corresponding smart space SMA may be described as:
SA=SnativeA ! {SXA↓|∀X,SMA⊂ SMX} ! {SYA↓|∀Y,SMY ⊂ SMA} where SA
X↓ denotes the set of services inherited from
different smart spacesSMX={X1,...} in the upper levels
of the hierarchy tree, andSA
Y↑ denotes the set of services
aggregated from different smart spaces SMY={Y1,...} in
the lower levels of the hierarchy tree. The SA
native set of services represents the set of native services in the smart space SMA.
In our demonstration scenario inheritance rules allow, for example, that users withinSMhome may access city-level services such as weather or traffic reports, which is represented asservice(weather)home
city↓native. On the other hand, aggregation rules allow, for example, that users within SMcity may access reservation services provided by SMrestaurant. This is described using the notation
service(reservation)cityrestaurant↑native.
Inheritance and aggregation rules may be combined to allow, for example, that users within the home loca-tion have access through inheritance to the reservaloca-tion service which is provided at the restaurant space, but has been made available to users in the city space by means of aggregation. This process may be described as service(reservation)home
city↓,restaurant↑native. Using this notation, the reservation service in the restaurant space is service(reservation)restaurant
native .
When considering devices and information context, the same notation can be used substitutingservicefordevice or context.
B. SETH Devices
To meet its goals, the architecture relies on a set of devices distributed throughout the environment. Accord-ing to the degree of autonomy and intelligence provided by the devices, mainly determined by its computational capacity to include agents, we can find different kinds of devices in a given SETH smart space:
Smart Space Agent Platform Device (device(SSAP)A). It contains the core of the agent platform which supports the existence of all other agents in the smart space. It specifically hosts the general purpose service and system agents, that is, all those agents that actuate at a global level in the space, without being associated to a specific sensor or effector. Generally, it contains the higher level agents of the system. It also contains those agents used to control non-intelligent devices, that is, devices with not enough processing or storage resources to host their own agents. Every smart space in SETH must have its own SSAP device.
System Devices (device(x)A). Sensors and effectors with a certain degree of autonomy. This autonomy may be provided by agents running over a Java virtual machine embedded on the devices themselves, or they may be controlled by agents residing in the SSAP.
Identification Devices (device(IDx,user)A).Each user must carry a mobile device, which is used to identify the user to the system and determine user location within the smart environment.
Personal Devices (device(P Dx,user)A).As an option, users may carry handheld, mobile devices -cell phone, PDA- which not only may provide the functionality of the identification devices above, but also hosts the necessary agents to learn, maintain and try to satisfy user preferences, and to display the adequate interfaces to the available services when needed. Personal devices are intended to move through different smart spaces in the system, sodevice(P Dx,user)Astates thatuser’s personal device xis atlocation A. The SETH architecture supports both users with personal devices and users without them. System Devices without agents depend directly on the SSAP, and they are linked to it by means of standard communication technologies, like X.10 or EIB for typical smart home devices or IR for remotely controlled appli-ances. System Devices with Agents, Personal Devices and the SSAP can communicate using TCP/IP. Fig. 2 shows the system architecture, where we can see the different communication layers.
The system has been developed over the open-source agent platform JADE.1Using an already established agent
platform releases us from the low-level tasks about agent life-cycle and message interchange. Using Java language ensures code portability to different machines. Further-more, JADE complies to the IEEE FIPA2standards, which
guarantees a certain degree of interoperability with other agent-based systems. Note that the JADE platform ex-tends to all elements in the smart space containing agents, and those agents exist inside a container associated to each element. The SSAP device hosts the main container of the platform. The personal devices have their own JADE agent platforms. Communications between different smart
1Java Agent DEvelopment framework (http://jade.cselt.it)
2FIPA is an IEEE Computer Society standards organization that
pro-motes agent-based technology and the interoperability of its standards with other technologies (http://www.fipa.org).
Figure 2. The SETH architecture
spaces, whether they are at the same level in the hierarchy or not, are treated as inter-platform communications and are performed via TCP/IP.
C. SETH Software Agents
As we have stated before, our smart spaces rely on software agents to provide their functionality. We may find different kinds of software agents in a typical SETH smart space:
• Smart Space Coordination Agents (agent(SSC)device(SSAP)A): Provides device and service discovery to all other users or agents in the smart space, and to SSC agents of other smart spaces. It resides in the SSAP devices, so for simplicity we use agent(SSC)A instead of
agent(SSC)device(SSAP)A
.
• Device Agents (agent(x)device(y)
A
device ): They are the agents directly controlling the devices within the smart space. They provide a unified interface to devices, so that other agents in the system may use them regardless of specific hardware issues. They are usually attached to the system devices themselves, outside of the SSAP devices.
• System Agents (agent(x)Asystem): They reside in the SSAP device, and add an additional layer of intelligence on top of the devices in the environ-ment through control and coordination mechanisms, providing functionality directly related to building management and security. Security agents and con-text agents fall into this category. Concon-text agents and context management are discussed in section IV. The security architecture for SETH is presented in [15].
• Service Agents (agent(x)device(y)
A
service ): These agents are intended to provide services directly to the user, and usually upon user’s request. They may rely on device agents, system agents or other service
agents to provide their functionality. In the SETH architecture, we distinguish two different classes of service agents:
– Persistent Service Agents: These agents provide services directly related to each specific smart space, such as climatization, lighting, or inter-faces to other services available in the space. Those services are usually required to be avail-able at any moment to every user in the space, and so these agents are always active in the SSAP device.
– Non-persistent Service Agents. These agents provide services more related to the user, such as content access or unified messaging. They are created by the SSC agent for each request of the service and destroyed once the use of the service has concluded. To allow these services to “follow” the user as he moves throughout the environment, these agents are able to move from one location to another when user location changes.
• Personal Agents (agent(P Ax,user)device(y)
A
): Per-sonal agents are directly associated to users. Each personal agent learns its user preferences and tries to adapt the environment to suit those preferences. Personal agents may issue requests to system, service and device agents on behalf of their users, and they can even negotiate with other personal agents when different user preferences raise conflicts. Personal agents are the very representatives of users to the environment, and they play a key role to achieve the perception of “smartness” from the users.
IV. SENSING THE ENVIRONMENT:THECONTEXT
AGENTS
As stated in section II, context management is a key issue for service personalization in smart spaces, since the
Software Agent Facts Database (Beliefs) Knowledge Database (Desires & Plans) Inference Engine Intentions External Context Internal Context Learning
Figure 3. SETH software agents as knowledge-based systems
system must be able to gather and interpret information about the users and their environment in an effective manner. Software agents in the SETH architecture are modelled as BDI agents, representing agent beliefs, de-sires and intentions as data structures which determine agent behavior. The basis of the BDI model is that an agent has beliefs about the world and desires to fulfill, which lead it to formulate intentions to act. Context handling concerns the way beliefs are acquired and shared among agents.
To map the functionality of the different software agents to their beliefs, desires and intentions we use the BDI-ASDP methodology. From a design point of view, we see SETH software agents as knowledge-based systems. Software agents have a facts database, where they store their beliefs about themselves and the world, aknowledge database which contains their desires and plans, and an inference engine, which continuously makes decisions about the agent beliefs and desires, triggering the specific agent intentions at each moment to fulfill the different goals. This can be seen in Figure 3. The inference engine of the software agents in the SETH has been implemented using JESS, which takes care of rule-based decision making. Agents knowledge database is comprised of JESS rules, which may be determined both at design time and at runtime (e.g. by means of automated learning techniques). Finally, our context handling architecture takes care of the adequate population of the facts database.
For the rule-based decision making system to react accordingly to changes in the environment, agents need to be aware of changes in the facts which could eventually trigger any of their rules, and this ’fact awareness’ must be maintained in real time, so that system reactions occur in a timely fashion. To support this continuous update of the facts database, our context handling architecture relies on a dynamic subscription mechanism. This means that software agents know which information they may need at each moment, and subscribe to the appropriate agent which generates or collects that information, so that they can be notified when relevant changes occur.
A. Context generation and context subscription
We can give a practical definition of context as “any information which may be of use to the system”. From
this point of view, any agent in the SETH architecture may be a context generator, as long as there is any agent potentially interested in the information it can provide. But for this context information to be available to other agents, any agent providing context must declare which information is able and willing to provide. This is accomplished via a registration mechanism analogous to the one used for service agents. Every agent in the SETH architecture know, upon examination of the different rules of their own knowledge databases, the information they can generate and share with other agents. If there is any information they are willing to make available to other agents, they register as context providers for the smart space they are located in, specifying the kinds of facts they may provide information about. Context providers may update their registration information dynamically should their ability or willingness to share information change.
Any agent may query a context provider for an spe-cific piece of information at any time. However, query mechanisms are not always the best solution. In particular, when an agent needs to be aware of an specific event (e.g. the temperature of a lab is above 40ºC), continu-ously querying the appropriate context provider (e.g. the temperature agent of the room) may not be an efficient strategy, as it generates a great deal of messages. Taking this into account, context providers allow other agents to subscribe to the information they generate, and they notify the subscribed agents upon change of the information they are subscribed to or when specific conditions stated in the subscription hold (e.g. when the room temperature is above 40ºC).
B. Context interpretation, aggregation and discovery According to the context definition above, sensors are the primary sources for context information, but they are not the only ones. Context may include information about the status of devices (e.g. whether an electronic lock is open or closed, or what interface is being displayed in a given device). There may be additional layers above the primary context information sources, due to the need for additional abstraction. In such cases, context interpreters subscribe to the primary information sources, interpret the context information received, and register as providers of the interpreted context information. A hierarchy of context providers at different levels of abstraction can be implemented by placing additional layers of context interpreters above them.
Usually, agents will need heterogeneous information about a given entity or class of entities in the system. For example, a power management agent may need to know the energy consumption at every device in a given floor, or it may need to know if any device is exceeding its assigned power quota. Though the power management agent could query or subscribe to every device for the information needed, it may be undesirable, specially if there are other agents potentially interested in that information (e.g. ecology agents). In such cases,
context aggregators are used to increase efficiency and maintainability. Context aggregators collect context about an specific entity or class of entities, subscribing to the necessary context providers, and register as providers of the aggregated context information, so that context retrieval of the aggregated information is easier and more efficient.
A special case of context aggregation is the location-specific aggregation of context providers, which plays a key role in context discovery processes. For each smart space, there is a Smart Space Context Discovery Agent (agent(SSCD)A
system), which aggregates the informa-tion about the context providers in its associated smart space. It does not know the information provided, but the agent who provides it. By arranging those agents in a hier-archy parallel to that of the smart spaces, context discov-ery may follow the same mechanism described for agent, device and service discovery in [14]. When an agent needs some information and does not know which agent to ask, it contacts the agent(SSCD)A
system of the smart space it is located in. The agent(SSCD)A
system checks if the info is provided by the context providers registered at this space, which may include the agent(SSCD)A
system associated to spaces situated at lower levels in the hi-erarchy. If no provider is found for the requested infor-mation, the request is passed to the immediate ancestor
agent(SSCD)A
systemin the hierarchy tree, which repeats the process. When the provider of the requested infor-mation is found, its address is returned to the requesting agent, so that it can subscribe to the information as usual. Figure 4 illustrates the hierarchical context handling mechanisms used in the SETH architecture for the par-ticular case of user location. Let us assume that we have deployed different kinds of sensors (RFID readers, ultrasound sensors, heat sensors, radio receivers...) in both the deskroom and the presentation room smart spaces. Each sensor has its own device agent (DA). When those agent start, they review the rules in their knowledge databases and register to the agent(SSCD)A
system (1), specifying the information they can provide to other agents. We now deploy Smart Space Location Agents (agent(SSL)A
system) in both rooms, which are context interpreters which are able to abstract the information provided by the sensors and to locate and identify users within the smart space. After reviewing their own rules, the location agents determine which information they need to know in order to function properly and query their appropriate agent(SSCD)A
system(2) for the agents which may that information. The context discovery agents return the addresses of the DAs which had registered to them (3), and the location agents subscribe to those device agents (4), specifying the conditions . Once each agent(SSL)A
systemis subscribed to the information they need, it may provide its functionality, and so it register to their associated agent(SSCD)A
system as provider of user location information for its associated smart space (5). To provide an efficient way to search for a given user in the floor, we add at floor level a User Directory
2nd Floor Smart Space
Deskroom Smart Space
SSCDA 1
Presentation Room Smart Space DA DA SSLA SSCDA UDSA 1 2 3 4 4 DA 1 4 SSCDA 1 DA DA SSLA 1 2 3 4 4 5 5 6 7 8 8 9 9 10 10
Figure 4. Context generation, interpretation, aggregation and subscrip-tion
2nd Floor Smart Space
Deskroom Smart Space
SSCDA
Presentation Room Smart Space Alice DA DA SSLA SSCDA UDSA DA SSCDA DA DA SSLA DA 1 1 1 2 Bob PA 3 4 5
Figure 5. Reaction to changes in the context
Service Agent (agent(U DS)f loorservice), which is a con-text aggregator intended to be aware of the location of any user in the floor. The agent(U DS)f loorservice queries the agent(SSCD)f loorsystem for the location information it needs (6), and it is told to query the different context discovery agents of the different rooms in the floor (7). Theagent(U DS)f loorservicedoes so, and the addresses of the different location agents are returned (8 and 9). Finally, the agent(U DS)f loorservicesubscribes to the location agents to be notified of any changes on the location information they provide (10).
After the process described above, we have the context hierarchy depicted in Figure 5. Now the system is ready to react to changes in the context. Let us imagine that user Alice enters her deskroom. The different sensors react to their presence and report the changes to the agent(SSL)deskroom
system (1), which interprets the new data, decides that Alice is in the deskroom and notifies the agent(U DS)f loorservice about it (2). If, for instance, Bob’s personal agent, located on the second floor, wishes to locate Alice, it can query the agent(SSCD)secondF loorsystem about it (3). The context discovery agent does not know that information, but knows there is an aggregator below in the hierarchy that could know about it, so it will return the address of the agent(U DS)f loorservice (4). Now the personal agent can query theagent(U DS)f loorserviceand finally locate Aliceat the presentation room (5).
V. MOBILE AGENTS FOR SERVICE PERSONALIZATION
The ultimate goal of any smart environment is to release users from the tasks they usually perform to achieve comfort and efficiency. We approach this problem by placing software agents between the users and the environment. In particular, in the SETH system we use
PA Context Agents Service Agents User Interface devices and agents 1 2 3 4 5
Figure 6. The Personal Agent as an intermediary between the user and the system
personal agents as the final intermediaries between the users and the different available services. Any specific service request coming from the user is directed to the personal agent, which then forwards the request to the appropriate service agent. In this way, a personal agent is aware of the different service requests made by its associated user. This, along with the knowledge about the context of every specific request, allows the agent to adapt to the user preferences by using different methods of personalization, like the approach proposed in [16] or the mechanisms described in the following sections. This makes the agent able to anticipate user desires and try to satisfy them in advance by issuing automated service requests on behalf of the user.
Interaction between the user and the service agent is usually performed through the use of context and interface agents. Figure 6 shows an example of such an interaction. Imagine a given user is in theSMpresentationRoomsmart space. This information is notified to the personal agent by the context agents (1). If the user acts over the light control panel to dim the lights (2), this action causes a message to be sent (3) to the user’s personal agent requesting the specific action –e.g. “dim the lights down to half intensity”. The personal agent then forwards the request to the appropriate service agent (4), which finally performs the operation. Eventually, the personal agent may learn that its associated user always sets the lights to half intensity after turning on the projector, being able to anticipate this action in subsequent times by requesting the service automatically on behalf of the user (5). A. The Personal Agent
Personal agents are the agents responsible of enforcing user preferences, and they need to be contacted whenever their associated users request a service. This may produce a high amount of messages in an application scenario with a certain number of potential users and available services. Should the personal agents be static, there would be a significant increase of inter-platform communication and bandwidth consumption when the user left the smart space where her personal agent resided. Taking this into account, personal agents in the SETH architecture move from one SSAP to another when required, thus effectively following user movements throughout the environment [17].
Personal agents reside originally in a given smart space, which is called the personal agent’s home agent platform
(HAP). A personal agent’s HAP is the SSAP which created the personal agent, and is usually associated to the user’s residence. The address of the personal agent of a given user is stored in her identification device, so that any SSCA can know where to locate the personal agent of any identified user.
To avoid unnecessary agent migrations, a personal agent is invited to leave a SSAPonlywhen its associated user is in another space and a service that can be per-sonalized to that user becomes active in that space. This can be triggered by a direct intervention from the user (e.g. the user activates an interface panel) or be automatic (e.g. a user enters a smart space where lighting can be personalized). If the personal agent accepts the invitation3,
it moves to the inviting SSAP, where it resumes execution and starts providing service personalization to its user. If the source SSAP for the migration is the personal agent’s HAP, the personal agent clones itself before moving. This clone is used to protect the integrity of the personal agent and to synchronize any changes to the user model when the personal agent returns to its HAP.
Since a user may move through many smart spaces in the hierarchy tree, moving the personal agent back to its HAP whenever the user moves may be very inefficient. In fact, since the hierarchy tree is built according to the containment relationships between spaces, we can assume that user movements are more likely to occur within adjacent nodes in the tree. To take advantage of this, when a userleavesa smart space4that is not the personal
agent’s HAP, the personal agent moves to the immediate ancestorSSAP in the hierarchy tree. This ensures that the personal agent of a given user resides either in the SSAP associated to the place where the user is located in or in a SSAP which is an ancestor of that SSAP. In this way, personal agents can be searched for efficiently when they are needed.
Making the personal agents move in the way described above may cause scalability problems at higher levels in the hierarchy. In our application scenario, the city SSAP would need to host the personal agents of all users roaming the streets, which is not desirable. To avoid this problem, the personal agent returns to its HAP whenever a user leaves a smart space whose immediate ancestor is also an ancestor of the personal agent’s HAP. Taking this into account, the mechanism used to search for the personal agents of an identified user is straightforward. First, the personal agent is searched for in the SSAP associated to the user current location. If it is not there, the search is propagated to the immediate ancestor. If the personal agent is not found and the next immediate
3It is the user’s personal agent who makes the decision of moving to
the inviting SSAP. The reasons because of which a personal agent may refuse to move to a SSAP can be diverse, ranging from knowledge that its associated user does not require personalization for a given service (e.g. lighting) to security reasons (e.g. the inviting SSAP is not trusted).
4Note that, due to the physical containment relationship between
spaces, leavinga space necessarily implies moving to a space that is at the same level or higher in the hierarchy tree. If a user moves to a space which is lower in the hierarchy, the new space is contained in the previous one, so the user has not left the previous space.
ancestor is also an ancestor of the personal agent’s HAP, the personal agent is finally searched for at its HAP.
Figure 7 illustrates personal agent mobility in our application scenario. Both the user Bob and its per-sonal agentagent(P Amobile,Bob)device(SSAP)
home
reside in the home smart space, which is also the HAP of the personal agent. Bob now leaves his home and goes for a walk through the city (1). His personal agent notices Bob is not at home, and performs any neces-sary actions in SMhome accordingly (e.g. turn off the lights), but stays at its HAP as long as Bob does not need any service. Now Bob approaches SMmonument (2) and presses the button of an interface panel there. agent(SSC)monument identifiesBobthrough his ID de-vicedevice(IDmobile,Bob)monument, and gains from this device the address of the personal agent (3). This address is of the form [email protected]. Since the monument is at monument.city, and thecityis an immediate ances-tor of the agent’s HAP, agent(SSC)monument contacts
agent(SSC)home (4) to request the personal agent to move toSMmonument. The personal agent is cloned and then transferred todevice(SSAP)monument(5), where it can attend Bob’s request.
Bob now leaves the monument and heads towards his workplace (6). Bob is now at citylevel, which is an ancestor of the agent’s HAP, so the personal agent moves back tohome(7), synchronizing any changes on the user model with the clone. When Bob enters his workplace building (8) he does not request any service, so there is no need for the personal agent to move from its HAP. First in-teraction with the system at the workplace is at the second floor, when he activates a interface panel there (9). This is again a request for a personalizable service (the user is requesting an interface which could be personalized), so agent(SSC)secondF loor tries to find Bob’s personal agent. Again, the address acquired is [email protected], and thesecondF looris atsecondFloor.workplace.city, so agent(SSC)secondF loorasksagent(SSC)workplace(10) and, since the personal agent is not there and the next immediate ancestor is also an ancestor of the HAP, it finally asks agent(SSC)home (11), which confirms the presence of the personal agent in the HAP. As in the previous case, the personal agent migrates from its HAP to the secondF loor (12), where it can provide its user the personalized services requested.
NowBobenters his deskroom (13). As thedeskroom smart space is lower in the hierarchy (it is at deskroom.secondFloor.workplace.city) there is no need for the personal agent to move if Bob does not re-quest a specific service. However, an automatic lighting personalization service is available at this space, and agent(SSC)deskroom tries to find the personal agent to see if Bob may desire to have this service. Following the same strategy that in the previous cases, it first asks agent(SSC)secondF loor(14). The personal agent is in the
secondF loorSSAP, so no more searches are needed and the personal agent moves to thedeskroomSSAP (15).
After some hours of work at his deskroom,Bobdecides
to go home. He leaves the deskroom (16) and the second floor (18), and his personal agent follows him (17 and 19, respectively), as, though he is not requesting any service, he is moving to upper levels in the hierarchy tree (secondfloor.workplace.cityandworkplace.city). When he leaves the workplace (20), the personal agent returns to the HAP (21), since the city smart space is an ancestor of the home. When Bob arrives home, he will find his personal agent there taking care of his preferences.
For users not having their own personal agents (e.g. casual visitors to the city), the system can generate temporary personal agents for them with a basic set of preferences, which can be then updated through config-uration or experience as usual. For this to be feasible, there must be a Temporary Personal Agent HAP, which is in charge of generating those agents, synchronizing the changes on them, and destroying them when they are no longer necessary. In our application scenario, this temporary HAP is at city level (with addressvisitors.city). B. Following the User throughout the Smart Spaces: Non-persistent Service Agents
As we saw in section III-C, non-persistent ser-vice agents (agent(N P)service) are created by the agent(SSC)X to address specific service requests made by users, and cease to exist when they are no longer needed. These agents are highly coupled to the specific requests they’re associated to, and therefor to the specific users who made the requests. When a user who is accessing a service provided by an agent(N P)service in a given smart space leaves this smart space, he is no longer accessing the service provided by the non-persistent service agent, and thus the agent could be terminated. This is not always the best strategy. The user could return to the smart space later and expect to resume access to the service, or even want to access the same service in another space. Although the user (or the agent(P A)) could re-issue the request in the new space, this may not always have the desired effect. Some services, such as access to multimedia content, may be required to hold their state between successive requests, to prevent the user, for example, from having to scroll to the desired slide of a presentation or having to select the desired scene of a DVD whenever the user wants to resume the operation of the service. For this kind of services, the goal is the perception of the service being following the user movements throughout the different smart spaces.
In the SETH architecture, user follow-up through the different smart spaces is achieved in a more effective and natural way, by making the non-persistent service agents able to move between different SSAPs. This allows these service agents to actually follow the user, stopping service execution when the user leaves a space and resuming it at the same point when the user enters a new space.
When a given user leaves the smart space where he is accessing a service provided by anagent(N P)service, the service agent asks theagent(P A) wether it wants it
City Smart Space
Workplace Smart Space 2nd Floor SS Deskroom HomeSS PA PA User Personal Agent SSCA SSCA SSCA 1 2 SSCA 3 4 5 PA 6 7 8 9 SSCA SSCA 10 11 12 PA 13 SSCA 14 PA 15 16 PA 17 18 PA 19 20 21
Figure 7. Personal agent mobility
to follow the user to the next space or not. The personal agent may then request the agent(N P)service to move, to terminate execution -e.g. the user no longer wants the service- or to wait there for further instructions -e.g. the user will return to the same space shortly-.
If the non-persistent service agent is requested to move, it will attempt to perform the migration. The migration may not succeed due to several reasons. Perhaps the destination SSAP has no resources to host the agent, or may not allow the agent to move due to security concerns. If the attempt to move is unsuccessful, the agent(N P)service will notify the agent(P A ) and ask for further instructions. If it is successful, it will attempt to resume the service at the new SSAP. This may involve contacting other service and device agents, and may require even to wait for resources if, for example, the devices required to provide the service are being used by another users or agents.
Figure 8 illustrates how non-persistent service agents can be used to make services “follow” a given user throughout the different smart spaces. User Alice is in her deskroom, having a video-conference provided by a non-persistent service agent (agent(N P SA)deviceservice,conf erence(SSAP)deskroom) through a device agent on her desktop computer. She leaves her deskroom without closing the conference, but brings with her her smartphone (1), and theagent(N P SA)service,conf erence asksAlice’s personal agent whether it should move to the personal device or not (2). The response is affirmative, and so theagent(N P SA)service,conf erencemoves to the smart phone (3), asks theagent(SSC)device(smartphone)
for the addresses of any device agents needed (4) and resumes service execution in the smart phone (5). Alice passes then through the secondFloor and workplace smart spaces (6) and, as the video-conference service is being provided by the virtual smart space created by the smart phone, there is no need for the agent(N P SA)deviceservice,conf erence(smartphone to move to any of these spaces. When Alice enters her car (7), her PA decides that, for safety reasons, the service must be no longer provided through the smartphone, and asks the
agent(N P SA)deviceservice,conf erence(smartphone (8) to try to move to thecarSSAP. The non-persistent agent moves to the new platform (9) and asks the agent(SSC)device(SSAP)car
for the addresses of the agents it needs to provide the service (10). In this case, there is no agent able to display video, and thus the service is turned into an audio conference through the car speakers (11). Alice drives home while going on with the conversation (12). When she arrives home and leaves her car (13), the process repeats to move the video conference service back to the smartphone (14, 15, 16 and 17). When she finally enters the home smart space (18), the video conference moves seamlessly to the living room TV (19, 20, 21 and 22).
VI. EXPERIMENTAL RESULTS
Since we have not yet deployed our architecture in an environment large and populated enough, we cannot evaluate the real impact of agent mobility on system performance. We have, however, designed a simulation scenario in our own Java testbed. An extension of the hierarchy tree depicted in Figure 1 has been modeled so that we can simulate bandwith consumption effects over communication channels while keeping the processing times in the SSAPs accurate. We have assumed 10 Mbps Ethernet links in workplace buildings, 50 Mbps WAN at city level, and ADSL (2Mbps for the downlink, 512 Kbps for the uplink) between the user residences and the city. We have measured the mean delay between service triggering (i.e. the user action which causes the service to be started) and the actual service provision (i.e. the final action performed by the system in response to the user action) for different service request rates. The simulations have been performed for services provided by persistent service agents, to isolate the impact of personal agent mobility on system performance.
Figure 9 shows the simulation results for both sta-tionary and mobile personal agents. We can see that, for low service request rates, the system performs better using stationary PAs, due to the overload introduced by agent migration. However, when the service request rate increases, inter-platform traffic between the smart space where the user is located and the HAP severely affects
City Smart Space
Workplace Smart Space
2nd Floor SS
Deskroom
Home SS
PA
User
Personal Agent SSCA SSCA
1
6
Smart Phone
PA
NPSA NPSA Smart Car
SSCA SSCA NPSA DA Device Agent DA 2 4 NPSA 3 5 SSCA NPSA DAPA PA NPSA 8 7 NPSA 9 SSCA 10 DA 11 NPSA DA 12 PA SSCA DA 16 NPSA 17 NPSA 14 13 15 18 PA NPSA 19 NPSA 20 SSCA 21 DA 22
Figure 8. Using mobile agents to make services “follow” the user
system performance, and so the system performs better using mobile personal agents. The intersection between both curves is at a rate of about eight service requests per second. We can expect that, in large and populated environments such as workplace buildings and cities, the actual service request rate will be above this value, thus taking advantage of the mobility of the PAs. Low service request rates may be expected in user residences, but in these cases the personal agents will not move (they are in their HAPs), so system performance will not be affected by unnecessary migrations.
Figure 9. Experimental results
VII. CONCLUSIONS AND FUTURE WORK
In this paper, we have presented a hierarchical ar-chitecture for developing smart environments using soft-ware agents. The main advantage of using agents is the
autonomy that they can provide. An intelligent agent bases its behaviour on a set of high-level goals, and determines autonomously the necessary actions to meet those goals. These actions may include interaction and cooperation with other agents. In fact, multiagent sys-tems are distributed syssys-tems, which made them very suitable for their application to smart home environments, where coordination of distributed sensors and effectors is needed. The use of a modular, hierarchical approach allows for high flexibility and scalability, which makes the solution applicable to different smart space scenarios, ranging from small smart workplace rooms like those described in [18] and [12] to large, hierarchically arranged spaces like the urban environment proposed by [11].
COBRA [13] is probably the research work most closely related to ours, as it uses software agents for their context-aware architecture, and defines a broker-centric management strategy for each domain, in a way quite similar to the role our SSCAs play in each smart space. However, COBRA focuses mainly on context sharing rather than service personalization, and personal agents are limited to personal mobile devices. In our solution, we consider the possibility of having users who do not always carry (or do not own) personal devices. To address these cases, we take advantage of personal agent mobility. This approach was first foreseen in [19], though the solu-tion proposed there still requires users to carry personal handheld devices. In addition, we have applied the mobile agent paradigm to non-persistent service agents too, so that services may effectively follow the users as they move throughout the environment.
There are many other promising avenues for further work in this area. We are now implementing new smart services in our own workplace and city environments to
check if the proposed architecture is flexible enough to handle them. We are also refining context management, with special interest in making user location more reliable and efficient. Finally, we are working on the security layer of the architecture [15], which is a critical issue for any smart space architecture intended to be deployed in real environments.
ACKNOWLEDGMENT
This work has been supported by the Spanish Ministry of Education and Science grant TSI2005-07384-C03-03 and by the Comunidad de Madrid grant CCG07-UAH/TIC-1648.
REFERENCES
[1] J. R. Velasco, I. Marsá-Maestre, A. Navarro, M. A. López, A. J. Vicente, E. d. l. Hoz, A. Paricio, and M. Machuca, “Location-aware services and interfaces in smart homes using multiagent systems,” inProceedings of the 2005 International Conference
on Pervasive Systems and Computing (PSC’05), Las Vegas, USA,
June 2005.
[2] D. J. Cook and M. Youngblood,Smart Homes, ser. Berkshire En-cyclopedia of Human-Computer Interaction. Berkshire Publishing Group, 2004.
[3] N. Jennings and M. Wooldridge, “Software agents,”IEE Review, pp. 17–20, January 1996.
[4] G. Chen and D. Kotz, “A survey for context-aware mobile com-puting research,” Dept. of Computer Science, Dartmouth College, Tech. Rep. TR2000-381, 2001.
[5] K. Cheverst, N. Davies, K. Mitchell, A. Friday, and C. Efstratiou, “Developing a context-aware electronic tourist guide: some issues and experiences,” inProceedings of CHI, Netherlands, 2000. [6] W. Conner, L. Krishnamurthy, and R. Want, “Making everyday life
easier using dense sensor networks,” inProceedings of UBICOMP, Atlanta, USA, 2001.
[7] S. Helal, W. Mann, H. El-Zabadani, J. King, Y. Kaddoura, and E. Jansen, “The gator tech smart house: a programmable pervasive space,”IEEE Computer, vol. 38, no. 3, pp. 50–60, 2005. [8] C. Becker and D. Nicklas, “Where do spatial context-models
end and where do ontologies start? a proposal of a combined approach,” in Proceedings of the First International Workshop on Advanced Context Modelling, Reasoning and Management
(UbiComp2004)., 2004.
[9] M. Mansukhani, “Service oriented architecture - whitepaper,” Hewlett-Packard Dev. Comp., Tech. Rep., 2005, available at http: //h20219.www2.hp.com/services/downloads/soa_wp_062005.pdf. [10] ADOBE, “Service oriented architecture,” Available at
www.adobe.com/enterprise/pdfs/Services_Oriented_Architecture_ from_Adobe.pdf, 2005.
[11] T. Kindberg and J. Barton, “A web-based nomadic computing system,”Computer Networks, vol. 35, pp. 443–456, 2001. [12] J. Yura, J. Nakazawa, and H. Tokuda, “Galaxy ds: Directory
service for service composition based on smart space structure,”
inProceedings of the 19th International Conference on Advanced
Information Networking and Applications (AINA’05), 2005.
[13] H. Chen, “An intelligent broker architecture for pervasive context-aware systems",” Ph.D. dissertation, University of Maryland, Bal-timore County, December 2004.
[14] I. Marsá-Maestre, “A hierarchical, agent-based architecture for smart spaces,” Grupo de Ingeniería de Servicios Telemáticos, Universidad de Alcalá, Tech. Rep. TR-2006-101, November 2006, available at http://www.it.aut.uah.es/ist/papers/TR2006-101.pdf. [15] I. Marsá-Maestre, E. de la Hoz, B. Alarcos, and J. R. Velasco, “A
hierarchical, agent-based approach to security in smart offices,” in
Proceedings of the 2006 Internacional Conference on Ubiquitous
Computing (ICUC 06), 2006, pp. 11–19.
[16] A. Ali Eldin, “Towards context aware personalized mobile ser-vices: An agent-based approach,” inProceedings of the
Interna-tional BETADE Workshop, 2002.
[17] I. Marsá-Maestre, M. A. López, J. R. Velasco, and A. Navarro, “Mobile personal agents for smart spaces,” inProceedings of the IEEE International Conference on Pervasive Services 2006 (ICPS
2006), Lyon, France, June 2006, pp. 299–302.
[18] B. Johanson, A. Fox, and T. Winograd, “The interactive workspaces project: Experiences with ubiquitous computing rooms,”IEEE Pervasive Computing, pp. 67–74, 2002.
[19] D. O. Chyi, “An infrastructure for a mobile-agent system that pro-vides personalized services to mobile devices,” Dartmouth College, Department of Computer Science, Hanover, NH„ Hannover, NH, Tech. Rep. TR2000-370, May 2000.
Ivan Marsa-Maestreis a PhD candidate at the University of Alcala. His research interests include agent-based systems, smart environments and mobile agent security. He received his MSE in communications engineering from the University of Alcalá. Contact him at the Department of Automatica at the University of Alcala, Edificio Politecnico, Ctra N-II, Km 32, 28871, Alcala de Henares, Madrid, Spain; [email protected]
Miguel A. Lopez-Carmona is an associated professor of Electronics Engineering at the University of Alcala. His interests are in the theory and practice of agent-based computing in e-markets. He received his PhD on Telecommunication Engi-neering from the University of Alcala. Contact him at Edificio Politecnico, Ctra N-II, Km 32, 28871, Alcala de Henares, Madrid, Spain; [email protected]
Juan R. Velasco is an associated professor of Telematics Engineering at the University of Alcala, where is the coordi-nator of the Telematics Services Engineering Research Group. His interest is focused on agent-based services personalization. He received his PhD on Telecommunication Engineering from Technical University of Madrid. He is member of the IEEE and the Computer Society. Contact him at Edificio Politecnico, Ctra N-II, Km 32, 28871, Alcala de Henares, Madrid, Spain; [email protected]
Andres Navarro is a PhD candidate at the University of Alcala. His research interests include agent-based systems, ad-hoc networking and routing in ad-ad-hoc networks. He received his MSE in communications engineering from the University of Alcala. Contact him at the Department of Automatica at the University of Alcala, Edificio Politecnico, Ctra N-II, Km 32, 28871, Alcala de Henares, Madrid, Spain; [email protected]
