Telecommunication Network and Services Department. Institut TELECOM SudParis. Paris, France. Abstractâ There are many devices embedded in a smart ...
A Context-Aware Resource Management Framework for Smart Homes Yunji Liang, Xingshe Zhou, Zhiwen Yu, Haipeng Wang School of Computer Science Northwestern Polytechnical University Xi’an, P.R. China
Bin Guo Telecommunication Network and Services Department Institut TELECOM SudParis Paris, France
Abstract— There are many devices embedded in a smart home environment. It is a challenge to operate these devices due to the heterogeneity and the mobility of them. In this paper, we propose a context-aware resource management framework, which aims to (1) discover available resources and update the states of those devices according to the changes of contexts; (2) allocate suitable resources to meet the needs of user tasks. Context-awareness facilitates decision making in the process of resource allocation by considering device states and user contexts including user situations, user tasks, device capabilities, and so on. A prototype system is implemented based on the context-aware resource management framework. The prototype system shows that the framework proposed is feasible.
mechanisms [3],[4],[5],[6]. The classical device discovery mechanisms such as Bluetooth [7] and Universal Plug and Play (UPnP) [8] are able to discover the surrounding devices and support the mobility of devices. However, those mechanisms do not support interoperations among devices. This dilemma makes a single device discovery mechanism infeasible in heterogeneous environments. In their paper, Raverdy et al. [5] present the design of a hybrid Multi-Protocol Service Discovery and Access (MSDA) middleware platform, which supports service discovery in heterogeneous and multi-protocol pervasive environments. The mechanism in the MSDA discovers the devices in distributed environments by multi hop network. However, due to the single-hop network in smart home, the MSDA is complex for the device discovery in the smart home.
Keywords— Context-aware; Resource management; Pervasive computing; Smart home; Elder care; Multimedia prompting
Furthermore, it is a challenge to select a suitable service for user tasks due to the differences of available devices. Generally, the process of allocating suitable resource is timeconsuming. When contexts are concerned, the decision-making process may filter lots of unrelated resources in the process of service selection. For instance, user location is one kind of important context in the decision-making process. A limited amount of information covering a person’s proximate environments is most important since the interesting part of the world around us is what we can see, hear, and touch [9]. Thus, the resource management system should allocate proximate devices for user and select the specific functions according to user contexts.
I.
INTRODUCTION
The population of the elderly is growing at a phenomenal rate. In view of cognitive decline, especially, memory, hearing and visual impairment for the elderly, the Smart Home (SH) has emerged as a potential approach to support old people to perform a variety of daily activities and make it possible for them to live independently [1]. With the vision of ubiquitous computing becoming reality, people will soon live in environments surrounded by networked computers and mobile devices [2]. The computing devices differ from each other significantly in their computational capabilities, supporting network protocols and available pervasive services on the concerned devices. In such highly heterogeneous environments, allocating a specific device for an application is impractical. Furthermore, lots of handheld devices such as smart phones and Personal Digital Assistants (PDAs) serve as the user terminals in smart home. Those dynamical and mobile devices have a significant effect on the implementation of pervasive services. In order to manage the heterogeneous devices in smart home, a Resource Management Framework (RMF) that can discover the accessible devices, provide uniform interfaces to the pervasive services hosted on the concerned device, and allocate suitable resources according to the current situation and user preferences is required. The heterogeneity and mobility of devices influences the availability of resources in the smart home. To solve this problem, much work has proposed the device discovery
To address the above issues, this paper introduces a context-aware resource management framework in smart home, which discovers the available devices based on the general device ontology in pervasive environments dynamically and allocates suitable devices according to users’ contexts and situations. Considering that the allocated devices might not exactly meet the needs of user task, we employ the content adaptation to ensure the tasks to run smoothly on the devices and enhance user acceptance. The rest of the paper is organized as follows. Section II reviews related work in the field of resource management. Section III primarily elaborates the architecture of the contextaware resource management framework. In Sections IV and V, we focus on the functions of two modules, device discovery and context-aware device allocation. A prototype system based on the context-aware resource management framework is presented in Section VI. This paper concludes in Section VII.
This work was partially supported by the National Natural Science Foundation of China (No. 60903125, 60803044), the High-Tech Program of China (863) (No. 2009AA011903), the Program for New Century Excellent Talents in University (No.NCET-09-0079), and the Specialized Research Fund for the Doctoral Program of Higher Education (No. 20070699014).
978-1-4244-8812-4/10/$26.00 ©2010 IEEE
II.
RELATED WORK
This section provides an overview of existing approaches that employ context information to assist device discovery and allocation in smart homes. The resource management framework consists of several components: device description, mechanisms on device discovery and device selection. A device is a combination of physical devices and the services on the concerned device. The physical devices are the hardware components of the device. To discover the services hosted on the concerned devices, a universal and understandable device description of heterogeneous devices is necessary. However, there has been no collective effort to come up with a framework to semantically describe devices in order to make semantic discovery possible and effective. Instead individual researches have produced device descriptions for different objects. FIPA Device Ontology [10] specifies a frame-based structure to describe heterogeneous devices and is intended to facilitate agent communication for content adaption. However, it merely describes the features of physical devices, such as the solution of its screen, the size of memory and so on. A device is the container of services. To describe a device in detail, the services hosted in the concerned device are also necessitated in the description information. The CC/PP specification [11] proposed by the W3C offers a RDF-based way to describe devices’ capabilities. However, the lack of expressivity makes it difficult to infer the semantic relationships between entities. Additionally, the Extensible Markup Language (XML) [12], [13] was introduced to describe a device in [14] for content adaption. This structured-language is not adequate to describe heterogeneous devices due to the weakness of scalability. Over the past decade, many resource management frameworks have been proposed [15], [16], especially the service discovery framework (e.g., UPnP or Bluetooth). One common limitation to them is that they are initially designed based on specific assumption about the underlying network, the users’ behaviour or the applications’ needs [5]. The interoperations among these frameworks are missing. Additionally, few contexts are taken into consideration in the design of service discovery framework. We argue that contexts will be very useful in the process of context-aware service selection. For example, in the case of a reminder service, the location of the user and the available terminals in the current location are very useful in the process of determining a suitable terminal to represent the reminder services. Additionally, it is likely to change the service in view of the device capabilities. Many projects have also proposed context-aware resource discovery framework [17], [18]. Q-CAD [19] is a Quality of Service (QoS) and context-aware resource discovery framework for pervasive environments. Q-CAD encodes both application profiles and utility functions using XML. Each application specifies the contexts parameters to be taken into consideration in the process of matching. The process of matching depends on the agreed, implicitly defined key-word match. However, XML is not adequate to describe a device due to its limited semantic information. Furthermore, the application does not know what kinds of service are provided in the heterogeneous and mobile environments. Generally, the
application needs schedule the interfaces on the concerned device to accomplish certain functions. How to match the needs of applications and capabilities of device is a challenge. Generally, the key-word based matching is used. However, the key-word based matching is not valid in some scenarios. Furthermore, the content adaption is essential due to the heterogeneity of devices’ capabilities. The content adaption makes sure the user task is executed smoothly on the target device. But very few resource management frameworks mentioned the functions of content adaption. In this paper, we propose a context-aware resource management framework. The framework presents a mechanism to discover devices based on device ontology in heterogeneous network. In the process of decision making, the framework utilizes the W3C Semantic Web Rule Language (SWRL) [20] and Description Logic (DL) [21] to match the requests of user tasks and the capabilities of devices and overcomes the weakness of key-word based matching. Finally, content adaption is supported in the framework to ensure the task to be executed smoothly on the selected device. III.
RESOURCE MANAGEMENT FRAMEWORK
In smart home, there exist lots of mobile and heterogeneous devices. We assume that all stationary devices belong to the same administrative IP domains. All those devices can be accessed in single-hop ad-hoc networks. Under this assumption, the architecture of the resource management framework is introduced. A. Requirements of Resource Management Framework Mobility and heterogeneity are the features of devices in a smart home. To manage the devices in smart home efficiently, the RMF should offer functions to discover available devices in heterogeneous networks and allocate appropriate devices to execute the user task in term of contexts. To fully achieve these functions, the requirements of the context-aware RMF are listed as follows: 1) Unified representation of devices The significant differences among hardware devices make it impossible to handle applications for every special device. In order to get rid of the heterogeneity of devices, a unified representation of devices is needed. The unified representation describes not only the composition of devices including hardware components and software components, but details of the external accessible interfaces and other important information such as the location and device type. The unified representation of devices abstracts all information of physical devices and organizes in a standard format, which benefits the understanding of devices and development of applications for users. More importantly, the discrepancies among physical devices can be hidden by using the uniformed representation. 2) Device discovery The heterogeneity of pervasive environments embodies in a variety of forms, including the heterogeneous networks the devices support, the different interfaces for the same or similar functions on distributed devices and the differences of device capabilities etc. The heterogeneity leads to only devices that
are advertised with the protocol they support being available. The RMF should provide the mechanism to support the interoperations among different networks such as Bluetooth or UPnP and expose uniform interfaces for user tasks. A user task should not care about what kind of device is available or how to call the interfaces on different devices, but only describe the expected services and detail parameters. 3) Context-aware device allocation Allocating the suitable devices according to the user contexts is a challenge. The mobility of devices makes it impractical to allocate a specific device for an application in advance. The resource management framework should be context-aware, which allocates the suitable devices for tasks according to current context. For example, in the case of a reminder service, the location of the user and the available terminals in the current location are very useful in the process of determining a suitable terminal to represent the reminder services. Additionally, it is likely to change the service in view of the device capabilities. Generally, the set of contexts includes plenty of information, such as user location, noise level, user preferences, and so on. The decision-making process takes the user task needs, user preferences and contexts as input, matches the available devices capabilities and task needs, and allocates suitable devices to execute user tasks. The context-awareness makes fully use of the dynamical contexts of the smart home and shields the effects of mobile devices. 4) Content adaptation The allocated device is not likely to fully match the required services. For example, a user task requires a picture to be shown in JPEG (Joint Photographic Experts Group) format, but the allocated device can only display the picture in BMP (Bitmap) format. In addition, the size of the picture should change with the resolution of the device. In such condition, the content adaptation is needed to make sure the task executed smoothly on the allocated device and provide high quality services for users. B. The Architecture of Context-Aware RMF The context-aware resource management framework is responsible for discovering devices in smart home, matching the requests of user tasks and the capabilities of devices, and allocating appropriate devices for user tasks. The architecture is shown in Fig. 1.
Figure 1. The architecture of context-aware RMF
As Fig. 1 shows, the context-aware RMF includes the following components: (1) Device Discovery Manager (DDM) discovers devices within heterogeneous networks and provides the device description of accessible devices in the environment. The device description not only presents the basic components of physical devices, but also the available services hosted on the devices. (2) Context Base (CB) stores all the contexts including user situation (e.g., user location) and preferences; CB provides a persistent storage for contexts. (3) Task Requirements (TR) abstracts the exact needs of user tasks and applications. The TR includes a semantic construct parameter that specifies the desired functionality and optional device constraints. (4) Device Allocation Manager (DAM) allocates suitable devices to execute a user task according to the three sources of inputs: DDM, CB and TR. The output of DAM is a set of available devices, which probably includes more than one device to execute a task collaboratively. Comparing with previous work, the context-aware RMF makes fully use of the contexts including the device states, user location and task requests to allocate devices, and to make sure the task executed smoothly on the target devices. In context-aware RMF, DDM is independent, which dynamically discovers the resource in the smart home periodically and aggregates the states of devices. When the state of a device changes, the device will post a message to the DDM and the state will be stored in the CB. Additionally, the DDM provides query interfaces for DAM to query available devices. When an application or user task is generated, the TR abstracts the needs of the task in the form of task ontology and passes the description of the task ontology to the DAM; On receiving the task description information, DAM gets the available devices by calling the query interfaces of DDM, then matches the requests of tasks and the capabilities of available devices, and ultimately allocates a suitable one to run the task. To make sure the task executed smoothly, the data preparation for content adaptation is optional. IV.
DEVICE DISCOVERY IN RMF
A. Workflow of Device Discovery In smart homes, there are many kinds of devices. Generally, those devices can be classified into stationary devices and mobile devices. Stationary devices have powerful computing capabilities and may support several network protocols, such as TCP/IP, Wi-Fi and Bluetooth. On the other hand, mobile devices are more likely to be resource-constrained devices, which have limited computing resources and only support a certain kind of network protocols. To manage all the computing resources in a smart home, the device discovery mechanism should support multi-protocols and provide query interfaces for external modules. The DDM in Fig. 1 can be decomposed into several components as shown in Fig. 2. The DDM includes server, adaptor, device pool (DP) and the devices distributed in heterogeneous networks. The server is in charge of discovering devices and monitoring the states of the devices. Adaptor, the bridge of heterogeneous networks, facilitates the transformation of messages. The device is the combination of a
understandable by other application agents. Furthermore, the device ontology, providing some details about the device in which it is hosted, will be necessary when a service involves a hardware device for service selection purposes. For example in the case of a reminder service, the solution of the device may be useful in the process of determining suitable device and the network context is used to determine the appropriate presentation method. Additionally, it is necessary to harness the inferential benefits of logical reasoning over such description in order to allocate a suitable device for user tasks.
physical device and the device agent hosted on the concerned physical device. The device agent is responsible for communicating with the adaptor. The device pool is a persistent storage of description information of available devices. As Fig. 2 shows, the server supports many network protocols and communicates with the devices distributed in heterogeneous networks through the adaptor.
sN ha k or w et
The workflow of DDM is presented as follows. The server periodically broadcasts the device discovery command, which is predefined and unique in the system. The device discovery command is interpreted into other forms of broadcast messages that are meaningful in different network protocols by Adaptors. It should be noted that the device discovery command is just a global command, which triggers the Adaptor to broadcast the device discovery message through the local network. The Adaptor is listening in the device discovery command from the server. On receiving the device discovery command, Adaptor is triggered to launch the broadcast message in the local network. All the devices located in the domain of the local network respond to the broadcast message and report the detailed descriptions of the devices’ capabilities. On the other hand, the adaptor listens to the responses from devices and submits all the device information to the server. The server aggregates all the device information and updates the content of Device Pool (DP). DP is the storage of available devices, which enumerates all accessible devices and the services they support. In DDM module, all those components are invisible for the external module except the Device Pool. The DDM provides public query interfaces to launch the information of available device for external modules.
has
e vic Ser
has Ha rdw are
Figure 2. Components of the Device Discovery Manager
In order to completely describe the details of a device, the device ontology contains four related components (see Fig. 3): hardware component, software component, network component, and service component, and other attributes, such as device name, location etc. In the hardware component, it presents the CPU, memory, storage and the resolutions of display in detail. All those information describes not only the capabilities of the device, but also the device loads. The software component describes all the information of software installed in the device, e.g., the name, vendor and version of software. The network component shows the network protocol the device supports, which is useful in heterogeneous network protocols. The service component contains the interfaces provided by the device and other description information about those interfaces. Through the service component, external module can learn about the functions of the device and execute a specific service by calling the interface. Additionally, other free attributes are necessary such as the location, device name and device type. Location details will be required when service selection needs to consider the location of the device in choosing the right service [22]. The device ontology aims to provide a general framework to describe all kinds of devices. In other words, the device ontology abstracts all the useful information and provides a unified semantic description of the physical device.
has So ftw are
B. Ontology-based Device Description To facilitate the management of devices, the device ontology is introduced to describe the detailed information of devices. In distributed environments, the ontology provides a unified representation of the device information which is Figure 3. Device ontology description
Fig. 3 illustrates the architecture of the device ontology. The device ontology not only illustrates the basic components of the device, but also provides the description of network interfaces. By using the device ontology, the relationships between entities can be expressed more clearly which makes it possible to reason about and derive knowledge from the given knowledge. C. Quantifying the Capability Index The device ontology describes the capabilities of a device, and extracts the features of the device in a uniform format. However, all the above device description is high-level and semantic-oriented. The quantification of a device is needed to indicate the computing capabilities of a device in the device ontology. In order to quantify the capabilities of device, the capability index is introduced, which indicates the extent of device’s availability. Generally, the capability index presents the capabilities of the devices. The higher the capability index is, the more likely to provide high quality service for users. Therefore, a method is introduced to calculate the capability index based on the device ontology. In set theory, the device ontology is a set of contexts, denoted with the letter Ω. Every context, symbolized with ci, in the device ontology is the element of the universal set Ω. The capability index is expressed according to (1), where Q represents the capability index.
Q = F (c1 , c2 ,..., cn )
(1)
To quantify the capability index of a specific device, there is no need to take all related contexts into account. Several critical contexts are selected from the device ontology as the parameters. Therefore, the capability index is calculated according to (2), where the constant M represents the number of the feature contexts and the variable βi indicates the weight of the context ci. M
Q = ∑ β ici
(2)
i =1
In view of the significant differences between stationary devices and mobile devices, the device type, QoS of the network and the feature of CPU are chosen as the input parameters. V.
CONTEXT-AWARENESS IN RMF
Considering the dynamical changes of user contexts in smart home, context-awareness is needed for the RMF. The context-aware RMF allocates the reasonable devices for user task according to the user contexts, device capabilities and requests of the user task. As shown in Fig. 4, the context-aware RMF is composed of Device Model, Task Model, User Model, Rule Bases and Runtime Model. The Device Model consists of lots of device ontology, which represent the instances of physical devices. The Device Model enumerates the available devices in the smart home and dynamical states according to the changes of
Figure 4. The composition of context-aware RMF
the device states. Task Model is the set of user tasks, which represent the ongoing to be executed tasks. When a user task is generated, a new instance of user task will be added in the Task Model. The User Model describes the contexts of the user, such as the location, preferences, etc. The Run-time Model, responsible for matching the requests of user tasks and capabilities of devices, plays an important role in the process of scheduling devices. The Rule Bases are the definitions of the relationships amongst concepts. The Rule Bases not only contain the predefined rules in the SWRL domain, but also support the rule customization. The custom rule is expressed in the SWRL which provides an easy to use mechanism for specifying event-condition action rules. When a rule is executed, a new fact/context is generated. The Device Model consists of concept and instance of devices. The concept of devices describes the knowledge of device and the relationships among entities. To represent a physical device and make the representation understandable for machines, we use the instantiated device ontology to describe a physical device. The instance of devices is the set of instantiated device ontology, which shows the current states of the device and lists the capabilities of every device. When a device is discovered, the device will give the device ontology a response. On receiving the response from the physical device, the device model generates an instance. Similarly, the Task Model includes the concept and instance of tasks. The concept of tasks represents the definitions of user task, and the instance of tasks details the requests and attributes of the task. When a new task is generated, the new instance of task will be added in the Task Model. Then the Run-time model will be triggered to infer according to the three models and rule bases. The run-time model is the core of the architecture, which is responsible for matching the requests of user tasks and the capabilities of devices and allocating a suitable device for user tasks. Allocating the appropriate devices for user tasks not only makes sure the quality of service, but enhances user acceptance for the task. However, how to select appropriate devices for tasks is still a challenge due to the complexity of contexts and task requirements.
The ontology-based reasoning is adopted for this purpose. Currently, many standardized languages have been proposed to represent ontology, such as Resource Description Framework (RDF) [23], OIL [24], DAML [25], Web Ontology Language (OWL) [26],[27], SHOE [28] and so on. OWL is used as the formal syntax for describing both structure and vocabulary of the ontology for the purpose of information sharing and logical reasoning. We use the OWL for ontological modelling and representation. OWL is based on the well-developed knowledge representation formalism for Description Logic. More importantly, DL supports the reasoning of the concepts and infers the relationships between concepts. Rule Bases are the definitions of the relationships amongst concepts and provide judgement standards for new knowledge. Generally, the Rule Bases not only contain the predefined rules in the SWRL domain, but also support the rule customization. Through the rules defined in the Rule Bases, new fact/context could be inferred from the existed knowledge. To facilitate the process of matching, the rule customization is necessary. Therefore, we defined a few rules as follows. It is believed that a limited amount of information covering a person’s proximate environments is most important for pervasive computing since the interesting part of the world around us is what we can see, hear and touch [9]. Thus, providing the proximate resource for user task is useful. In context-aware system, location is a kind of very important contexts. The position of user in the RMF is regarded as a Filter, by which all available devices are classified. Based on this assumption, Rule 1 is proposed and represented in the SWRL (see TABLE I). In Rule 1, the context of location is used as a filter. The property hasLocation of class Person and that of class Device are used to select devices from all the available devices in the smart home. Only the devices satisfying the Rule 1 are likely to be allocated for the tasks. Based on Rule 1, the RMF maintains an available device list in current user position. All the devices in the device list serves as candidates for user task. TABLE I.
RULE 1 AND ITS FORMALIZATION IN SWRL Definition of Rule 1
Semantic
The allocated resource should be close to users, which convinces users’ interactions with devices. *
Expression in SWRL
*
P :Person(?x) ∧ P:hasLocation(?x,?y) ∧ D :Device(?z) ∧ D:hasDeviceName(?z,?t) ∧ D:hasLoation(?z,?s) ∧ → SWRLB:equal (?y, ?s) ∧ T*:Task(?q) T:hasDevice(?q, ?t) *. “P”,”D”, and ”T” are three namespaces, which are defined in the original ontology.
In order to hide the differences of interfaces, all user tasks are described in task ontology files, which indicate the requirements of user tasks. For applications, they do not need to care about the specific interfaces. They are just responsible for implicitly describing the task requirements. To match the capabilities of devices and the requests of user tasks, Rule 2 is proposed and presented in SWRL (see TABLE II).
TABLE II.
RULE 2 AND ITS FORMALIZATION IN SWRL Definition of Rule 2
Semantic
Expression in SWRL
The services with the similar or same name are consistent for user tasks and devices. T*:Task(?x) ∧ T:hasRequest(?x,?y) ∧ D*:Device(?z) ∧ D:Service(?s) ∧ D:hasServiceName(?s,?a) ∧ D:hasDeviceName(?z,?t) ∧ D:hasService(?z,?s) ∧ SWRLB:containsIgnoreCase (?y, ?s) → T:hasDevice(?x,?t) ∧ T:allocateService(?x,?a) *. “T” and ”D” are namespaces defined in the original ontology .
On receiving the Task Requirements, the RMF matches the capabilities of available devices with task requirements. To match the requests of user task and the capabilities of devices, we use the similarity of class to make the decision. In the device ontology, the class service is defined, which describes the features of a specific service. The class service provides the information about the services hosted on the device concerned. The service classes in device ontology are structured in a hierarchical tree with sub-class inheriting all properties from their super-classes. For example, the class multiMediaService, a sub-class of class service, illustrates the features of multimedia service on the concerned device. According to Rule 2, the property hasRequest of task class and the property hasServiceName of service class are compared with each other. If they are consistent, the concerned device will be added into the set of target devices, which buffers all the usable devices to execute the user task. There might be more than one device in the set of target devices to execute the task. In this case, Rule 3 as shown below is proposed to select the device with higher capability index in order to provide better quality of service. TABLE III.
DEFINITION OF RULE 3
Rule Name
principle
Rule 3
The higher capability index, the better quality of service to perform the user task.
Additionally, to make sure the task be executed smoothly on the allocated device and enhance the user acceptability, the content adaptation is introduced. The content adaptation determinates the appropriate presentation method according to the user preference, situation context and the device or network context. We employ a generic and flexible N×M-dimensional (N2M) recommendation model, elaborated in our pervious work [29], to implement the content adaptation according to the user context and device capabilities. To illustrate the algorithm, the following scenario is taken into consideration. Suppose that the user is watching TV in the living room and his cell phone is at hand. The ontology of TV provides a service display to show image and message on its screen; and the cell phone has the service displayImage to display image in the jpg format on the phone. When a
medication reminder task is generated, the context-aware RMF will be activated to allocate a reasonable device to present the reminder. The reminder task needs the service displayImage to show an image in bmp format. On receiving the request, the RMF will get all the available devices in user’s current location, i.e., TV and cell phone. Then, the RMF will match the similarity between the requests and device capabilities, and get the set of target devices. In this scenario, the set of target devices includes TV and cell phone. Next, the RMF will select a device from the set of target devices for the user task according to the capability index. TV will be allocated for its higher capability index. Finally, the content adaption is needed to make the image show on the terminal according to its resolution and supported format. VI.
PROTOTYPE IMPLEMENTATION
We have built a multimedia prompting system based on the context-aware resource management framework for the elderly. In the multimedia prompting system, the reminder task determines a suitable device according to the devices’ capabilities and the remainder information is presented in different forms such as image, voice and text according to the capabilities of accessible devices. Furthermore, the user preferences and context are incorporated in the design of the prompting system. The multimedia prompting system is developed and deployed in the Intelligent Assistive Technology and Elderly Care Lab (IATECL) - a smart home in NorthWestern Polytechnical University (NWPU), China. The IATECL aims to extend the time to live independently for the elderly by a variety of intelligent assistive technologies. Amount of hardware sensors were deployed in the lab, including Ubisense system [30], RFID sensors, pressure sensors, and other basic sensors such as light/temperature sensors and noise sensors (see Fig. 5).
Figure 5. The IATECL lab in NWPU
The multimedia prompting system is implemented in the Java language. We adopted OSGi (Open Services Gateway initiative) [31] to construct the system architecture. All components in the system are capsulated in the form of OSGi
bundles and the communication among bundles is implemented by the Event mechanism. The OSGi bundles are mounted on the Event bus and listen in the related events. We use Protege [32] to construct the ontology files, including device ontology, task ontology and person ontology. In the processing of matching the capabilities and needs, we employ the Jena [33] API to implement the rule-based reasoning. In a particular scenario, an elderly is watching TV in the living room, and the telephone is ringing. When detecting the telephone state, a user task reminding the user to pick up the hook is produced. According to the device located in different rooms, the RMF will allocate a suitable device to execute the task. If the user is in the living room, the devices in living room are the candidates. Because the TV has higher capability index than the monitor, the prompting information will be displayed on TV like Fig. 6(a). When the elderly is reading newspaper in the study room, a medication reminder will be displayed in voice-based presentation like Fig. 6(b).
Figure 6. Context-aware reminder presentation
VII. CONCLUSION AND FUTURE WORK A context-aware resource management framework is presented in this paper. The framework aims to overcome the challenges caused by the heterogeneity and mobility of devices in smart homes. The context-aware framework outperforms traditional resource management systems in three folds: First, it introduces a device discovery mechanism based on the universal device ontology to manage the device in heterogeneous network. Second, rule-based reasoning is employed in the process of matching requests of user task and the capabilities of devices. Third, to make sure the task executed smoothly, the content adaptation takes charge of shielding the differences of interfaces and enhancing the user acceptability. A prototype system of multimedia prompting based on the context-aware RMF is implemented, which validates the practicability of the framework. In the current prototype system, we conducted an experiment to execute the atomic services. Our future work will focus on the complex service, which are decomposed into plenty of atomic services, and make sure the atomic services of the complex service are executed in the accurate sequence. REFERENCES [1] M. Chan, D. Estève, C. Escriba, and E. Campo, “A review of smart homes—Present state and future challenges,” Computer Methods and Programs in Biomedicine, vol.91, no.1, pp.55-81, 2008.
[2] Z. Yu, Y. Nakamura, D. Zhang, S. Kajita, and K. Mase, “Content provisioning for ubiquitous learning,” IEEE Pervasive Computing, vol. 7, no. 4, pp. 62-70, Oct.-Dec. 2008. [3] P. Bellavista, A. Corradi, R. Montanari, and A. Toninelli, “Context-aware semantic discovery for next generation mobile systems,” IEEE Communications Magazine, vol. 44, pp.62-71, Sep. 2006. [4] A. Wils, F. Matthijs, Y. Berbers, T. Holvoet, and K. De Vlaminck, “Device discovery via residential gateways,” IEEE Transaction on Consumer Electronics, vol. 48, no. 3, pp.478-483, Aug. 2002. [5] P.G. Raverdy, O. Riva, A. de La Chapelle, R. Chibout, and V. Issarny, “Efficient context-aware service discovery in multi-protocol pervasive environments,” in Proc. Of the 7th International Conference on Mobile Data Management (MDM’06), 2006, p.3. [6] A. Padmanabhan , Shaowen Wang , S. Ghosh , and R. Briggs, “A selforganized grouping (SOG) method for efficient grid resource discovery,” in Proc. of the 6th IEEE/ACM International Workshop on Grid Computing, 2005, p.312-317. [7] Bluetooth SIG, “Bluetooth protocol architecture version 1.0,” Bluetooth white paper, Sep. 1999. [8] UPnP forum, “UPnP device architecture 1.1,” Available: http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf [9] B. Schilit, N. Adams, and R. Want, “Context-aware computing applications,” in Proc. of 1st International Workshop on Mobile Computing Systems and Applications, 1994, p.85. [10] “FIPA Device Ontology Specification,” Foundation for Intelligent Physical Agents, Geneva, Switzerland. 2002. [11] (2010) The W3C website. [Online]. Available: http://www. w3.org/Mobile/CCPP/ [12] T. Bray, J. Paoli, M. Sperberg-McQueen, and E. Maler, “Extensible Markup Language (XML) 1.0 W3C Recommendation,” Available: http://www.renderx.com/~renderx/Demos/fo2html/xml.pdf. [13] (2010) The XML Schema website. [Online]. Available: http://www.w3.org/XML/Schema. [14] R. Eisinger, M. G. Manzato , and R. Goularte, “Devices descriptions for context-Based content adaptation,” in Proc. of the Third Latin American Web Congress (LA-WEB’ 05), 2005, p.121. [15] Luc Clement, Andrew Hately, Clause von Riegen, Tony Rogers. UDDI spec technical committee draft, Oct. 2004. [16] E. Guttman, C. Perkins, J. Veizaders, and M. Day, “Service Location Protocol, Version 2,” IETF RFC 2608, June 1999. [17] G. Lee, P. Faratin, S. Bauer, and J. Wroclawski, “A user-guided cognitive agent for network service selection in pervasive computing environments,” in Proc. of the 2nd IEEE Int'l Conference on Pervasive Computing and Communications (PerCom’04), 2004, p.219. [18] F. Zhu, M. Mutka, and L. Ni, "Splendor: a secure, private, and locationaware service discovery protocol supporting mobile services,” in Proc. of the 1st IEEE Int'l Conference on Pervasive Computing and Communications (PerCom’03), 2003, p. 235. [19] L. Capra, S. Zachariadis, and C. Mascolo, “Q-CAD: QoS and context aware discovery framework for mobile systems,” in Proc. of Int'l Conference on Pervasive Services (ICPS'05), 2005, p.435. [20] I. Horrocks, P. F. Patel-Schneider, H. Boley, S. Tabet, B. Grosof, and M. Dean, “Swrl: a semancit web rule language combing owl and ruleml,” W3C Member submission, Tech. Rep., 2004. [21] F. Badder, D. Calvanese, D. McGuinness, D. Nardi, P. Patel-Schneider, “The description logic handbook: theory, implementation, and applicatons”, Cambridge University Press, New York, 2003. [22] A. Bandara, T. Payne, D. Roure, and G. Clemo, “An ontological framework for semantic description of devices,” in Proc. of the 3rd International Semantic Web Conference (ISWC’04), 2004. [23] The webpage about RDF from W3C website. [Online]. Available: http://www.w3.org/RDF/ [24] The webpage about OIL from ontoknowledge. [Online]. Available: http://www.ontoknowledge.org/oil/ [25] (2010)The DAML website. [Online]. Available: http://www.daml.org/ [26] G. Antoniou and F. Van Harmelen, Web ontology language: OWL, S. Staab, R. Studer, Ed. Berlin, Germany: Springer-Verlag, 2003. pp. 67–92. [27] D. L. McGuinness and F. van Harmelen, “Owl web ontology language overview,” W3C Recommendation, Tech. Rep., 2004. [28] The webpage about SHOE from the cs.umd website. [Online]. Available: http://www.cs.umd.edu/projects/plus/SHOE/
[29] Z. Yu, X. Zhou, D. Zhang, C.Y. Chin, X. Wang, and J. Men, “Supporting context-aware media recommendations for smart phones,” IEEE Pervasive Computing, vol. 5, no. 3, pp. 68-75, July-Sep. 2006. [30] The website about Ubisense. [Online]. Available: http://www.ubisense.net/ [31] OSGi Alliance, “OSGi service platform core specification release 4,” [Online]. Available: http://www.osgi.org. [32] HP Labs, “Jena - a semantic web framework for Java,” [Online], Available: http://jena.sourceforge.net/ [33] (2010) The webpage introducing Protégé, [Online], Available: http://protege.stanford.edu
