- Email: [email protected]
OSGi-based smart home architecture for heterogeneous network
Expert Systems with Applications 39 (2012) 12418–12429
Contents lists available at SciVerse ScienceDirect
Expert Systems with Applications journal homepage: www.elsevier.com/locate/eswa
OSGi-based smart home architecture for heterogeneous network Sheng-Tzong Cheng, Chi-Hsuan Wang, Gwo-Jiun Horng ⇑ Department of Computer Science and Information Engineering, National Cheng Kung University, Taiwan
a r t i c l e
i n f o
Keywords: OSGi UPnP DPWS Smart home SOA
a b s t r a c t With the development of home network and service applications, different protocols and transmission modes are proposed. There are more digital devices and home appliances which compliance to the protocols. The proposed protocols are different and they are usually unable to communicate with each other; we design and implement a Service-Oriented Smart-Home Architecture to integrate protocols which are popular such as UPnP, Jini, DPWS on OSGi framework and collaborating Tmote, Zigbee and Bluetooth to converge various service oriented applications. Furthermore, with the well-developed Tmote, Zigbee and Bluetooth technology, majority of devices has been developed to support these technologies, we propose three new base drivers to integrate different devices communication protocol on our platform. Additionally, we propose a Service Resolving Bundle to complement the drawbacks of OSGi mechanisms. However, OSGi services with constructs of additional description are stored in our proposed Service Resolving XML (SRXML). Also, the service user may invoke the service of this bundle to get additional information of the aimed services. The architecture utilized with service-oriented mechanisms to accommodate applications which are implemented across different domains and allows the system components to interact with one another. Ó 2012 Elsevier Ltd. All rights reserved.
1. Introduction With the development of networking and Internet technology, there are growing numbers of digital devices and home appliances which support the plug-and-play ability on the home network. The devices and home appliances such as digital camera, television, mobile phone, refrigerator, air conditioner, washing machine and others are developed to comply with different home network communication protocols. The connection of electronic devices is realizing the vision that Mark Weiser described years ago (Weiser, 1991): our environment is filling with networked devices which are in a growing number. More services are expected to be provided in the future home. Currently the home networking technology is still in a middle of development, there are various protocols available to accommodate the communication between devices and appliances such as Universal Plug and Play (UPnP), Java for Intelligent Network (Jini), Devices Profile for Web Services (DPWS), Digital Living Network Alliance (DLNA) and etc. This situation results non-conformity of general available home network applications and in extensibility for users to set up their digital home environment. Many researches have been devoted to the service discovery or delivery protocols with service oriented mechanism including UPnP, Jini, Service Location Protocol (SLP) and Bluetooth SDP. These ⇑ Corresponding author. E-mail address: [email protected] (G.-J. Horng). 0957-4174/$ - see front matter Ó 2012 Elsevier Ltd. All rights reserved. http://dx.doi.org/10.1016/j.eswa.2012.04.077
protocols facilitate us to establish a dynamic connection between services or devices by integrating automatic query mechanism. They are designed to build a heterogeneous network framework to ease the use of services by user from the service providers. Each of these protocols has its own communication mechanism and characteristics. As an example, both UPnP and Jini technology supported devices which have plug-and-play ability, but both of these protocols use different method for service discovery. UPnP uses a special variant of the HTTP protocol for UPnP devices to communicate with control point, but Jini requires a central registry for Jini devices to register with via UDP multicasts using a proprietary protocol (Obiltschnig, 2006). Besides dealing with the communication protocol issue, home network is also unable to avoid the problems of dynamically varying home environment and distributed connection. Since there are mobile devices connected to the home network with distributing, it often happens that the devices were disconnected dynamically, which means that the services configuration in the smart home is usually dynamic. Furthermore, smart home should not only execute the commands which are received from the residents, but also collecting context information actively from environment. With the context information collected, system will infer the current user scenario and makes suitable reaction to provide comfortable environment for resident (Wu, Liao, & Fu, 2007). To deal with the whole operation mentioned, system needs to control and communicate with all the devices distributed in the home network. Therefore designers of the innovative home applications are facing three
S.-T. Cheng et al. / Expert Systems with Applications 39 (2012) 12418–12429
12419
Fig. 3. Service-Oriented interactions.
forming to open standards (Wacks, 2001). Here we propose a service-oriented architecture (SOA) based on OSGi OSGi, collaborate with UPnP, Jini and DPWS with the integration of Bluetooth, Zigbee and Tmote Support.
2. Related work Fig. 1. Conventional Smart Home Architecture.
The Open Services Gateway Initiative OSGi is an independent, non-profit corporation working to define and promote open specifications for the delivery of managed services to networked environments, such as homes and automobiles. These specifications define the OSGi Service Platform, which consists of two pieces: the OSGi framework and a set of standard service definitions. The OSGi framework, which sits on top of a Java virtual machine, is the execution environment for services. The OSGi framework was originally conceived to be used inside restricted environments, such as the set-top box in Fig. 2.
main challenges in this pervasive environment: dynamicity, heterogeneity and distribution. Furthermore, with the well developed Bluetooth technology, majority of digital devices have been developed to support Bluetooth. These devices comprised from different domains such as multimedia, data communication, office appliance and others to fulfill human being living demands. It is easy to see a device which is developed to support Bluetooth, for an example, mobile phone. In the mean time, there is a trend showing that Bluetooth enabled devices have become popular and it is can be saw everywhere in our living environment. Therefore, it is needed to fully utilize this communication capability. Additionally, wireless sensor network such as Zigbee and Tmote are playing more and more important role in smart home nowadays. It is usually needed in a smart home to collect environment data. Furthermore, it can be used to accommodate the controlling of the home appliance. It is a trend to accommodate the extensibility of the wireless sensor network in a smart home. In the light of the requirements mentioned above, a smart home should comply with the emerging computer technologies and appropriately fulfill human requirements. Regarding to the mass potential consumer market, we develop smart home with con-
The framework can be divided in two main elements: (1) A services platform. (2) A deployment infrastructure. A services platform is defined as a software platform that supports the Service Orientation interaction depicted in Fig. 3. This interaction involves three main actors: service providers, service requesters and a service registry, although only the service registry belongs to the services platform. In the Service Orientation interaction, service providers publish service descriptions, and service requesters discover services and bind to the service providers. Publication and discovery are based on a service description.
Fig. 2. OSGi overview.
Fig. 4. Bundle Life-Cycle.
2.1. The OSGi framework
12420
S.-T. Cheng et al. / Expert Systems with Applications 39 (2012) 12418–12429
In the context of OSGi, a service is described as a Java class or interface, the service interface, along with a variable number of attributes, the service properties that are name and value pairs. Service properties allow different service providers that provide services with the same service interface to be differentiated. The service registry allows service providers to be discovered through queries formulated in LDAP syntax. Additionally, notification mechanisms allow service requesters to receive events signaling changes in the service registry; these changes include the publication or retrieval of a particular service. Deployment activities are realized according to a well defined series of states depicted in Fig. 4; these states correspond to the bundle life-cycle. Bundles can be dynamically installed, started, stopped, updated and uninstalled. During the execution, the bundle perform state transition which is controlled through OSGi module management API. The following describe bundle states (http:// en.wikipedia.org/wiki/Service-oriented_architecture, http://publib.boulder.ibm.com/infocenter/ledoc/v6r1/index.jsp?topic=/com. ibm.rcp.tools.doc.appdev/smfbd_concepts_blcycle.html): (1) INSTALLED – the bundle has been successfully installed; (2) UNINSTALLED – the bundle has been successfully uninstalled and no longer exists in the framework; (3) RESOLVED – the bundle is installed, and its dependencies have been met. This state indicates that the bundle is either ready to be started or has stopped; (4) STARTING – a temporary state that the bundle goes through while the bundle is starting; (5) STOPPING – a temporary state that the bundle goes through while the bundle is stopping; 6) ACTIVE the bundle is running. 2.2. Service dependency management Service dependency management includes all the activities necessary to create binding between logical bundles during execution. This includes service publication, discovery, binding and adaptation with respect to changes due to dynamic availability (the arrival or departure) of services that are being used by a bundle during execution. Service dependency management is the key for building applications for the OSGi framework. Unlike code dependencies, service dependencies are not guaranteed, or managed, by the framework; this means that a physical bundle can be activated, even if services required by the logical bundle are not available. Service dependencies can be declared in the manifest file, but currently the OSGi specification indicates that they are declared for information purposes only.
Fig. 5. An OSGi application.
Fig. 5 depicts a typical OSGi application modeled as a series of logical bundles that are connected through the provided and required services. Sensor bundles are connected to physical sensors such as motion detectors, smoke detectors or cameras. A monitor polls the sensors and responds to particular situations for example by sending an e-mail to an administrator or by writing a log. The monitor also uses the services provided by an HTTP server to register a servlet so that management can be done remotely through a web page. In example above, the monitor’s logical bundle uses services provided by other logical bundles to accomplish its task. In this case the monitor bundle is responsible for discovering the services it requires. On the other side, the logical bundles that provide services are responsible for publishing them in the service registry. During execution, the different services exhibit dynamic availability as they are introduced or removed from the execution environment as a consequence of physical bundle deployment activities. It can be supposed, for example, that new sensor bundles can be introduced into the execution environment at any time, without the need of shutting down the system. Logical bundles are responsible for binding to newly arriving services or releasing departing services. Dynamic availability of services requires an application to be capable of dynamic assembly and dynamic adaptation. 2.3. Service components The Service Binder introduces the concept of service component to the OSGi framework. A service component is similar to the concept of a logical bundle but the difference is that multiple service components can be deployed inside a single physical bundle. A service component (see Fig. 6) declares a set of provided service interfaces, and a set of required service interfaces. During execution, an instance of a service component implements the provided services and it is connected to other instances to create an application. Service properties identify the instance and they are used when its services are published in the service registry. Provided and required service interfaces along with service properties represent an external view for the component, and they are a part of the application logic. This external view is implemented by a component implementation that can also provide certain control interfaces and it has some dependencies. Control interfaces implement the inversion of control pattern and they are provided so that the execution environment can manage instance’s lifecycle. Implementation dependencies represent dependencies from the component implementation on resources that
Fig. 6. A component class.
S.-T. Cheng et al. / Expert Systems with Applications 39 (2012) 12418–12429
12421
Fig. 7. The UPnP base driver architecture.
Fig. 8. The UPnP device interfaces.
Fig. 9. An example of Jini with OSGi operation.
are delivered along with the component (such as libraries or binary files) or they represent deployment dependencies.
In order to instantiate UPnP devices, developers must register services implementing the interfaces represented in Fig. 8 and services provided by the org.osgi.compendium bundle. The exporter is registered as ServiceListener (OSGi alliance) with the framework and it automatically exposes on the networks which each UPnP Device service registered with the registration property UPNP_EXPORT (OSGi alliance). The importer listens to the advertisements sent on the networks by external devices and registers with one or more UPnP Device services of the framework. Even if it is not required by the specification, the devices which are imported by the Felix base driver are labeled with the registration property UPNP_IMPORT (Felix).
2.4. Existing smart home networking for OSGi The Fig. 7 shows a simplified component view of the base driver. The driver is composed by two components, the exporter and importer; both using the CyberDomo library, which is a modified version of the library released by the ‘‘CyberLink for Java’’ project (CyberGarage), maintained by the Domoware project (Domoware). The library implements a full UPnP stack. The base driver acts as a bridge between OSGi and the UPnP networks.
12422
S.-T. Cheng et al. / Expert Systems with Applications 39 (2012) 12418–12429
Fig. 10. Global system modularity.
Working with UPnP Device from the OSGi point of view means to operate with services; the discovery, controlling and managing event phases of the UPnP protocol are naturally mapped to the OSGi service layer, which allows publishing, find, bind and notify events. There are some different aspects to work with UPnP in OSGi with respect to other UPnP libraries, due to the basically centralized nature of the OSGi registry opposed to the distributed approach used in UPnP networks; some hints are provided in the section ‘‘Writing UPnP Devices and Control Points’’. Consider the following example, illustrated in Fig. 9: a service that controls a lamp through the X10 protocol registers itself, and its Jini compliance, in the OSGi framework. The Jini Driver detects the presence of the service and exports it to a lookup service in the Jini network. If a Jini client wants to use the lamp service, it contacts the Jini LUS and retrieves the lamp service proxy. Next, the client sends commands via the proxy to the original lamp service, which forwards them to the lamp device. Note that this is the usual process for the Jini client and it unawares that the Jini lamp service was exported from the OSGi framework. Our DPWS Base Driver is designed to gain modularity (Fig. 10) so that it is capable to deal with the use case variety. Thus, only a precise set of bundles is useful for every use case. Bundles can be installed on-demand thanks to the capabilities of the underlying OSGi platform. DPWS defines the interaction between devices and clients (a.k.a. control points). Three main technical use cases are defined in the next sections: the generic network control point use case, the specific application client use case, and the specific DPWS device use case. In this work, our major contributions are (1) Transcode signal mode in integrated heterogeneous network to increase extendibility and enable communication for more networks. (2) Add task controller to increase system performance and enable resource assignment. (3) Add three kinds of bundle base driver (Bluetooth, Zigbee, T-mote) on OSGi platform. 3. Home application design
telecommunication operators, service providers, manufacturers and software vendors. They come along with market expectations for enriched multimedia activities, home surveillance and home care services for the disabled or elderly people (Aiello, 2006). As a result, there are lots of hard challenges for the achievement of these envisioned scenarios in the home network. But generally, these challenges are emphasized by the openness of the home network environment: (1) Dynamicity due to device availability, device context, user location and activity. (2) Distribution due to the natural location of devices in the home. (3) Heterogeneity due to hardware, software and protocol variety laid by the market evolution. (4) Embedded constraints due to device low cost drawn by the consumer electronics market. In order to face these challenges, application flexibility and development simplicity are demanded in home network. Service Oriented Architecture and component approach in the software development meet some of the requirements. The technological specification of the platform achieves the needs of flexibility and the device availability management is simplified. We have focused the effort and contribute at the design of our service oriented drivers and its implementation relying on the concept of ‘‘service platform’’. This architecture further answers the needs for managing distributed aspects and protocol heterogeneity in a transparent way for the developer while keeping the implied overhead below reasonable barriers. 3.2. Service Oriented Computing and local networks Service Oriented Computing consists of modeling an application into logical entities which are providing functionalities and there are other entities which are using those functionalities. A piece of functionality which is able to be invoked is called a service. The description of a set of operations is called a service interface. A logical entity which is providing a service is called service provider and an entity which is using a service is called service user. The complete chart of the Service Oriented Architecture includes an entity which is called service registry, which is responsible for storing the description of available service providers (Fig. 15). Service provider first publishes their description in the service registry. The description contains service interface and specific distinguishing properties of the service provider. When a service user tries to request a service, it will actively request for the service list from the service registry, this activity is called active discovery mode. There is another passive discovery mode which means the service user listens to service registration events, but this mode is only implemented when the service user knew the needed service interface and specific properties in advance. The advantages of Service Oriented Computing are: (1) Abstraction: The organization of third-party entities is considered as a service composition. Home devices are represented as black boxes. (2) Loose coupling: Providers and clients only share a service interface. Clients are independent from provider implementations. Substitutability is stressed by service discovery filters that consist of a simple interface name and descriptive properties. (3) Separate administration: Composed entities have distinct lifecycles. Consequently, Service Orientation brings the abstraction needed in the composition of heterogeneous device features and the flexibility needed for the application resiliency to the home network dynamics.
3.1. Home application requirements
3.3. Component orientation in service oriented applications
In the development of the smart home, people proposed many scenario and use cases to provide future vision for us. These scenarios and use cases are mostly done by researchers such as
With the property of being complimentary of Service Orientation, component orientation is also needed in the home application design. This approach models the applications into a high-level
12423
S.-T. Cheng et al. / Expert Systems with Applications 39 (2012) 12418–12429
Fig. 11. Platform-centric architecture.
service composition whereas the implementation of every identified network entity follows the approach. Advantages of the component approach are: (1) Code structuring: every networked entity is implemented as a logical code unit. (2) Separation of the business logic and the nonfunctional aspects: service distribution, service dynamicity and service (protocol) heterogeneity have to be managed transparently for the business developer. Containers are responsible for the management of these non-functional aspects. (3) Inversion of Control: The lifecycle of the component is managed outside of the component and its inner business logic. The control of this lifecycle is given to the containers. As a conclusion, Component Orientation approach leads us to accommodate application modularity to every involved entity in the whole application. It makes the management of complex non-functional aspects transparent to the business developer while the whole application composition is left to the administrator. As Thierry Coupaye et al. write in Collet, Coupaye, Chang, Seinturier, and Dufrêne (2007), component approaches are used in a pre-facto integration mode where all the components have to obey the same component model. On the other hand, Service Orientation is needed in a post-facto integration mode where every software entity has to be integrated just as it is with its own behavior.
won’t provide access to their devices to any operator or device (for safety, security and obviously business considerations). Devices are dynamic, based on various protocols and provide information in heterogeneous ways. We believe that, in order to realize the vision of sophisticated pervasive services in the home, it is necessary to build an open computing framework to run user-related services on home gateways. Such framework (Bottaro, Gérodolle, & Lalanda, 2007) should abstract the developer from low level details related, in particular, to service and communication technologies. 4.2. The service platform concept
4. OSGi-based smart home mechanism
In this vision (Bottaro, Simon1, Seyvoz, & Gérodolle, 2008), the application design is modular thanks to the component approach of the platform and every device feature, i.e. every service, is reified on the platform. In order to enable application components to dynamically compose those services, they are registered in a common service registry on the platform. We consider that the service platform is the smart dynamic receptacle of pervasive entities. This adaptable receptacle turns pervasive software composition into the composition of uniform service components. The main role of the platform is to adapt to the environment in locally representing all the relevant external entities with their specific context on the platform.
4.1. The platform-centric vision
5. OSGi-based smart home architecture
As previously introduced, we are working on an open serviceoriented computing architecture for the home. This architecture comprises network-enabled devices and computing platforms connected through field buses. Computing platforms often play the role of network gateways. Such gateways are already presented in many houses (telecommunication Internet gateways, TV connected set-top-boxes or utility service gateways) and it is likely that future homes will become host several, heterogeneous computing platforms (Fig. 11). Gateways provide the resources needed to run higher level services which are making use of the connected devices. The purpose is to coordinate multiple devices and to ensure natural, sometimes invisible, interactions with the users. These interactions are obviously directed by high level goals that can be set by the user or by Internet services to which the user has subscribed. Some electronic devices can be exclusively connected to a given gateway. For instance, a home control gateway can coordinate the behaviors of specific devices like shutters or heaters. This approach meets proven market constraints which state that most manufacturers
With the capabilities of OSGi, home applications can be maintained under a generic environment which comprising several heterogeneous frameworks. We now discuss how OSGi accommodate
Export
Service Provider
Import
Service API
Service User
Fig. 12. Service Oriented Architecture in OSGi.
12424
S.-T. Cheng et al. / Expert Systems with Applications 39 (2012) 12418–12429
this heterogeneous framework to allow the maintenance of the applications from different domain. OSGi platform (Alliance, 2005) is one of the main standard execution environments which allowing application reconfiguration at runtime. The model is designed based on Service Oriented Architecture which is relying on a service registry and service event mechanism. Therefore, the service oriented mechanism is implemented in OSGi platform in the following pattern. Each of the service provider, service consumer and service interface are concluded in different bundles separately (Figs. 12 and 13). Firstly, the bundles will import service API package from the service API bundle to gain the communication capability with OSGi environment. Secondly, regard to the Fig. 13, the functional component in service provider bundle will first register itself with the service registry bundle. When service user bundle online, the relevant functional component will request service information from service registry bundle. After the service registry bundle reply, then only service user bundle able to bind with the relevant service bundle (Describe how the bundles work together reference to the picture). This environment enables the bundles to be installed and uninstalled at runtime and the bundles are able to gain communication ability with the OSGi environment through the service API.
Bundles
Service provider
Functional Component
Service User
Service Registry
Database
1. Register
3. Reply Binds 2. Request
Service Provider
Service Consumer
Fig. 13. Service Oriented Architecture in OSGi.
5.1. System architecture Fig. 14 depicts our OSGi home network architecture. The OSGi gateway serves as the central coordination point for managing the home network, spanning multiple heterogeneous communication technologies. The OSGi specifications enable service providers and application developers to deploy and to manage in-home network services and devices. Because OSGi specifies only the application programming interface (API) instead of the underlying implementation, OSGi gateway is able to be both platform- and application-independent. This independence gives application developers and service deploying considerable operating and design freedom to distinguish their offerings. Open specifications promote application development that increases interoperability and reduces the time to market for new services. Other OSGi benefits include multiple service support, security, service collaboration, and multiple network support. It is the last benefit that come of particular interest here, and we explore it in greater detail later. The OSGi specification includes a framework, resembling an embedded application service for dynamically loading and managing software components, bundles. These bundles can be dynamically instantiated by the framework to implement particular services. Additional framework components include HTTP support services, logging functionality, and the Device Access Specification (DAS) Services Gateway Initiative. The DAS allows multiple devices to be discovered and their services advertised, by the framework so that they can be made available to other devices, services and applications. With the modular architecture mentioned above, we are able to integrate the devices and services from different domain into our own OSGi framework. The modular design enables the remote devices and services to appear as local entities on our OSGi framework. When a client wants to request for these services, they first request the relevant service bundle on our OSGi framework. Next, the client sends commands via the bundle which forward them to the services. On the other hand, the devices and services on our OSGi framework are able to appear as valid entities in other domain if these devices and services are compliant with the specific domain. The base drivers detect the presence of the service from our OSGi
Fig. 14. Our OSGi-based smart home network architecture.
S.-T. Cheng et al. / Expert Systems with Applications 39 (2012) 12418–12429
12425
Fig. 16. Tmote base driver architecture. Fig. 15. Bluetooth base driver architecture.
service registry and export it to the relevant domain Control Point. This will make the exported service appears as a local entities in the point of view of other clients which are in the same domain. If a client wants to use service, it will contacts the relevant control point and retrieves the service proxy. Next, the client sends commands via the proxy to the original service, and then the proxy will forward the commands to the original service entity. 5.2. Bluetooth base driver We have been developing a Bluetooth base driver to ease the usage of Bluetooth devices in OSGi environment. This Bluetooth base driver is composed by two parts: Importer and Exporter. Importer is responsible to listen to the advertisements on the networks by the Bluetooth devices and services. Then it will import all the discovered services and devices into OSGi environment, making them appear as valid OSGi entities and fully accessible by other OSGi entities (Fig. 15). On the other hand, Exporter is registered as ServiceListener with the OSGi framework and it responsible to export the OSGi entities which is compliant to the Bluetooth profile to the Bluetooth environment automatically, making them appear as virtual Bluetooth services and devices and fully accessible by other Bluetooth entities. Even it is not required by the OSGi specification, the imported and exported devices and services are registered with the registration property BT_IMPORT and BT_EXPORT correspond to their situation. In order for Bluetooth devices to communicate properly, we have been developing this Bluetooth base driver with conform to the Bluetooth specification. The Bluetooth specification, like any other spec, defines the standard that a Bluetooth device should adhere to, as well as the rules which are needed to be enforced when communicating. The Bluetooth protocol stack and profiles together comprise the Bluetooth specification.
On the other hand, Exporter is registered as ServiceListener with the OSGi framework and it responsible to export the OSGi entities which is compliant to the Tmote profile to the Tmote environment automatically, making them appear as virtual Tmote services and devices and full accessible by other Tmote entities. Even it is not required by the OSGi specification, the imported and exported devices and services are registered with the registration property TMOTE_IMPORT and TMOTE_EXPORT correspond to their situation. In order for Tmote devices to communicate properly, we have been developing this Tmote base driver with conform to the Tmote specification. The Tmote specification, like any other spec, defines the standard that a Tmote device should adhere to, as well as the rules which are needed to be enforced when communicating. The Tmote protocol stack and profiles together comprise the Tmote specification. 5.4. Zigbee base driver We have been developing a Zigbee base driver to ease the usage of Zigbee devices in OSGi environment. This Zigbee base driver is composed by two parts: Importer and Exporter. Importer is responsible to listen to the advertisements on the Zigbee networks by the devices and services. Then it will import all the discovered services and devices into OSGi environment, making them appear
5.3. Tmote base driver We have been developing a Tmote base driver to ease the usage of Tmote devices in OSGi environment. This Tmote base driver is composed by two parts: Importer and Exporter. Importer is responsible to listen to the advertisements on the Tmote networks by the devices and services. Then it will import all the discovered services and devices into OSGi environment, making them appear as valid OSGi entities and fully accessible by other OSGi entities (Fig. 16).
Fig. 17. Zigbee base driver architecture.
12426
S.-T. Cheng et al. / Expert Systems with Applications 39 (2012) 12418–12429
as valid OSGi entities and fully accessible by other OSGi entities (Fig. 17). On the other hand, Exporter is registered as ServiceListener with the OSGi framework and it responsible to export the OSGi entities which is compliant to the Zigbee profile to the Zigbee environment automatically, making them appear as virtual Zigbee services and devices and full accessible by other Zigbee entities. Even it is not required by the OSGi specification, the imported and exported devices and services are registered with the registration property ZIGBEE_IMPORT and ZIGBEE_EXPORT correspond to their situation. In order for Zigbee devices to communicate properly, we have been developing this Zigbee base driver with conform to the Zigbee specification. The Zigbee specification, like any other spec, defines the standard that a Zigbee device should adhere to, as well as the rules which are needed to be enforced when communicating. The Zigbee protocol stack and profiles together comprise the Zigbee specification.
6. Analysis and discussion In this section, we analyze system performance under three different models. We assumed that there are n clients requesting service at the same time; each service involves m Service Providers (SPs) of y Control Points (CPs) and costs each provider p computation time units. Each service has to interact with the CP with j messages, and it costs h network traffic units to transmit one message, each CP has to interact with the server with z messages and it costs e network traffic units to transmit one message. Each client sends request to the server and costs i network traffic units to transmit one message. To perform a service invoke task in a conventional smart home architecture mentioned above, each client must send service request to the server and then the server interacts with these y CPs by sending z messages to accomplish theses service requests. Each CP then sends j messages to the SP to invoke the requested services. After receiving data from different SP passed by CPs, the server processes these data, integrates them and returns the final results to the clients. Analysis is shown in Table 1, in which CP stands for ‘‘Control Point’’ and SP stands for ‘‘Service Provider’’, (⁄n), (⁄y) and (⁄m) represent the possible numbers of the associated entities and 1 n in the CP and SP columns means each of them accepts 1 n service requests, thus changing the workload of its network traffic and computation. As for the performance analysis of our architecture, clients query the service directory first to retrieve information about SP and obtain the service reference of the corresponding SP. Then the client interacts with m SPs remotely by sending j messages to each. When a client receives data that are returned from m
SPs, it processes them and costing q computation time units for each and then integrates them. Performance analysis is shown in Table 2. Table 3 shows the performance analysis of the P2P SOA with MA (Wu, Liao, & Fu, 2007). First, the clients query the service directory to retrieve information about SPs, and then create Mobile Agents (MAs) embedded with interaction logic based on service requirements. After that, every client sends its MA to SP, and since MA represents the client, the SP is able to interact with the MA locally and directly. Observing the computation load part in these three tables, the computation loads are the same comparing our architecture with the P2P SOA with MA model. It is a bit heavier for the computation load in the conventional architecture because the server needs to process and integrates data from different CPs. In the P2P SOA with MA model, the server load is distributed to SPs. Although this kind of distribution seems effective, it is not suitable for SPs which is lack of computation power. Based on our architecture, the server computation load is distributed among n clients and this kind of distribution seems fair. As for the network part, the clients handle more traffic in our architecture because they need to get service reference from the supplemental bundle additionally. It is not easy to compare network traffic in our architecture and in P2P SOA with MA model because there are different types of network traffic units. Note that our architecture which is utilized with the base driver helps to pass by the interaction between the client and CPs and hence the decrease of the server network traffic comparing with the conventional smart home architecture. Comparing network traffic of the client of our architecture with other model, the total traffic of the client of our model is greater because of getting service reference. But it provides a facility in the architecture which the other does not.
7. System evaluation To implement our proposal, we selected the open source OSGi Service Platform, Knopflerfish version 2.0.5 which led and maintained by Makewave (Knopflerfish OSGi). It is an open software implementation of the OSGi framework. We set up the framework and implemented it at the National Cheng Kung University Aspire Home for Quality Life. The Jini base driver is supported since OSGi specification version R3 and UPnP base driver is adopted. We used Jini version 1.2.1 (Community Resources for Jini), Odonata DPWS base driver 1.0.6 (InfraGforge), Domoware UPnP Base Driver version 3.0.2 and Control Points and Light devices correspond to DPWS, Jini and UPnP have been implemented on the prototype. Also, we developed the Control Point which is managed in the base
Table 1 Performance analysis of conventional smart home architecture. Conventional architecture
Network traffic ⁄
Computation load
Scenario
Client ( n)
Server
Client request server Server request CP CP request SP SP start service SP return data CP return data Server processes data Server integrates data Server returns results
i
i ⁄n e⁄z⁄y⁄n
Total
⁄
CP ( y) ln e⁄z e⁄z⁄n h⁄j⁄m h⁄j⁄m⁄n
⁄
SP( m) l n
Server
SP(⁄m) l n
h⁄j h⁄j⁄n p p ⁄n
e⁄z⁄y⁄n
h⁄j⁄m n⁄j⁄m⁄n e⁄z e⁄z⁄n
h⁄j h⁄j⁄n q⁄y⁄n q ⁄n
i ⁄n
i ⁄
2⁄n ⁄(i + e⁄z⁄y) 2i 2⁄(2⁄n⁄(i + e⁄z⁄y) + h⁄j⁄m⁄n⁄(y + 1))
2⁄n ⁄(e⁄z + h⁄j⁄m)
2⁄h⁄j⁄n
q⁄n⁄(l + y) n⁄(q⁄(y + l) + p⁄m)
p p ⁄n
12427
S.-T. Cheng et al. / Expert Systems with Applications 39 (2012) 12418–12429 Table 2 Performance analysis of our proposed architecture. Our architecture Scenario
Network traffic ⁄
Client ( n)
Client queries service registry Client queries service reference Client requests SP SP start service SP return data Client processes data Client integrates information
i i i⁄j⁄m
Total
2⁄i⁄(l + j⁄m) 2⁄i⁄n⁄(3 + 2⁄j⁄m)
Computation load Service registry
Supplemen bundle
⁄
Client (⁄n)
SP( m) l n
SP(⁄m) l n
⁄
in i⁄n i⁄j i⁄j⁄n p p ⁄n
i⁄j⁄m
i⁄j i⁄j⁄n q⁄m q i ⁄n
i⁄n
2⁄(i⁄j i⁄j⁄n)
q⁄(l + m) n⁄(q + m⁄(p + q))
p p ⁄n
Table 3 Performance analysis P2P SOA with MA. P2PSOA with MA
Network traffic
Senario
Client (⁄n)
Computation load Service directory
SP(⁄m) l n
Client (⁄n)
SP(⁄m) l n
⁄
Client queries service directory Client sends MAtoSP SP start service SP process data SP returns MA with data Client integrates results
i k
in
i+k
(i + k) (i + k)⁄n
Total
2 (i + k) i ⁄n 3⁄i⁄n + i⁄m⁄n + 2⁄k⁄m⁄n + 2⁄k⁄n
(i + 2k) (i + 2k)⁄n
k k⁄n p p ⁄n q q ⁄n q q n⁄(q + m⁄(p + q))
(p + q) (p + q)⁄n
Fig. 18. Performance evaluations of different interaction models.
drivers of Bluetooth, Tmote and Zigbee. We connected the Tmote audio player, Tmote coffee machine and Zigbee light devices in the Aspire Home and all the connected devices are controlled by Bluetooth enabled hand phone through a media center as graphical user interface. While every device connected to the different network they belong to, the corresponding base driver bundle will automatically import the devices from each different network into OSGi framework. As a result, we are able to inspect the attendances of the devices from different network domain on the OSGi service registry. We implemented a scenario that shows us the view of the power of the collaboration of different network. In this scenario, we assume that John has signed a maintenance contract for his OSGi residential gateway. One day, John comes back home from work and starts using his Bluetooth enabled mobile phone to control the devices in his house. First he switches on the light of the house once he enters the door. He then opens his media center and sits down to have a break in the living room while he playing on a movie. In the meantime, John controls the coffee machine to make a cup of coffee. After that John sitting in front of the media center and he turns off the light of the house into movie mode, while he enjoying the movie and his coffee. The scenario above includes lots of service registration, discovery and invocation in our OSGi framework. Firstly, when John
Fig. 19. Smart home platform offered by TOUCH center.
comes back from work, his Bluetooth enabled hand phone automatically connect to his home’s Bluetooth network. The Bluetooth base driver on our OSGi framework inspects the attendance of the phone, detects the Bluetooth identify number and automatically imports it into our OSGi framework. Since then the house knew that the phone will be the remote control for the devices. Before John switch on the light through his phone, the Bluetooth base driver converts the light devices into virtual Bluetooth light devices and allow John to control them. Once John sitting down in the living room and plays a movie on the media center, the OSGi framework receives the control signal forwarded from the Bluetooth base driver to the media center whereas an OSGi entity and allowing the phone to be remote control. The Bluetooth Enabled phone discovers the attendance of Tmote coffee machine through the service registry of OSGi framework. This allows John to invoke the machine to make a coffee. Then, The Tmote coffee machine receives control signal by Tmote base driver whereas a proxy which is forwarding the signal sent by the Bluetooth Enabled phone. Finally, John controls the light devices to turn to the movie mode to provide a comfortable movie watching environment. This scenario may lead you to
12428
S.-T. Cheng et al. / Expert Systems with Applications 39 (2012) 12418–12429
Fig. 20. Home control center interface on PDA, Zeus.
understand how Tmote, Zigbee and Bluetooth act in our OSGi framework. To study the performance of different interaction models (conventional smart home architecture and our architecture), we conducted experiments with our prototype implementations. We used a task controller to initialize the execution of a new task and to measure the turnaround time of execution in each experiment. A task is defined as a sequence of executable procedures on devices distributed over the network. In our experiment, the OSGi platforms have to collect data from devices and integrate the data as well as to perform inferring to produce the result upon receiving new task. Our experiments are described below. In the first scenario (conventional smart home architecture), there is a single OSGi platform connected with five devices through CPs from different domain via Ethernet locally as we shown in Fig. 1: Tmote device, Zigbee device, Bluetooth device, DPWS device and UPnP device. Each task is defined as sequentially gathering data from five devices and then performs integrating and reasoning procedures in OSGi platform. The time to integrate and reasoning and the data retrieval latency are both set as 100ms. In this work, we explained the different between conventional smart home and our integrated heterogeneous network (UPnP, Jin, Service Location Protocol (SLP) and Bluetooth SDP etc.) regard to communication protocol interfaces, which are built between corresponded protocol transcoding services. With protocol transcoding services we can perform data communication which is including data sending and receiving, this capability increases the extendibility of heterogeneous network. Fig. 18 shows the experiment results. Compared to conventional smart home architecture, the turnaround time is decreased drastically with our architecture. The performance results are gained from the direct interaction between client and the proxy of service provider and the decreased number of interaction between client and server. Because of the services are invoked locally in our architecture, most of the costs come from the data transferring latency. Consequently, the experiment result shows us our architecture helps to reduce the task execution by local execution of services. This work demonstrates implementing the system in a realistic smart home, a platform offered by the TOUCH center (TOUCH Center Home) as show in Fig. 19. Additionally, a user living in the smart house was emulated. In the emulation experiment, the system runs from 12:00 AM to 11:59 PM. The experiment was repeated for one week without pre-designing any scenarios before emulation. Users randomly generated actions using a PDA (Fig. 20) and media center based on their own preferences.
8. Conclusions The device and service discovery mechanisms of OSGi enable the creation of advanced home networking services. As illustrated in the preceding usage scenario, OSGi can serve as an effective bridge across disparate networking technologies, making new device interactions possible and leading to services within the home that can fully leverage the growing diversity of devices and better serve the needs of end users. The OSGi platform allows third-party application developers to quickly and easily develop new in-home network services that can incorporate a multitude of device technologies. Device and service discovery techniques within OSGi help to integrate otherwise isolated device technologies, allowing compound cross-technology services to be delivered within the home by multiple vendors. Also, because OSGi specifications are hardware-independent, they can be widely deployed on a variety of hardware and software platforms, unconstrained by the multiple device types in the home. Finally, OSGi specifications define service gateways, not simple routers or bridges. This allows intelligent end-user services, not just simple network connections, to be created and managed within the home network. Moreover, OSGi enables remote service management by third parties. This capability creates opportunities for service packages to be developed and offered to end users. Such service packages enable a service provider to assume all responsibility for provisioning, configuring, managing, and ultimately delivering home network services to subscribers. Discovery techniques allow these third parties to tailor services based on dynamic configurations of home networking elements, intelligently responding to the presence or absence of certain devices within the home. This effectively reduces the complexity seen by the end user, increases the flexibility of service offerings, and enables more rapid deployment of home networking services. References Aiello, M. (2006). The Role of Web Service at Home. In Advanced international conference on telecommunications (AICT/ICIW), Guadeloupe, French Caribbean, February 2006. Bottaro, A., Gérodolle, A., & Lalanda, P. (2007). Pervasive Service Composition in the Home Network. In: 21st IEEE International Conference on Advanced Information Networking and Applications, Canada, May 2007. Bottaro, A., Simon1, E., Seyvoz, S., & Gérodolle, A. (2008). Dynamic Web Service on a Home Service Platform. In 22nd International conference on advanced information networking and applications, March 2008. Collet, P. Coupaye, T., Chang, H., Seinturier, L., & Dufrêne, G. (2007). Components and Services: A Marriage of Reason, Technical, Report I3S/RR-2007-17-FR, May 2007. The Community Resources for Jini Technology. http://www.jini.org/. CyberGarage. http://www.cybergarage.org/net/upnp/java/index.html.
S.-T. Cheng et al. / Expert Systems with Applications 39 (2012) 12418–12429 Domoware. http:// domoware.isti.cnr.it/. Felix. http://svn.apache.org/viewvc/felix/trunk/upnp/basedriver/src/ main/java/ org/apache/felix/upnp/basedriver/util/Constants.java?view=markup. InfraGforge: Amigo. http://gforge.inria.fr/frs/?group_id=160&release_id=1804. Knopflerfish OSGi. http://www.knopflerfish.org/. Obiltschnig, G. (2006). Automatic Configuration and Service Discovery for Networked Smart Devices. In Electronica Embedded Conference Munich, 2006. OSGi Alliance. (2005). OSGi Service Platform Core Specification Release 4, October 2005. OSGi alliance. Available:http://www.osgi.org/javadoc/r4/org/osgi/framework/Service Listener.html. OSGi alliance. Available: http://www.osgi.org/javadoc/r4/org/osgi/service/upnp/ UPnPDevice.html#UPNP_EXPORT.
12429
OSGi alliance. Available: http://www.osgi.org. Open Services Gateway Initiative, Device Access Specification, http://www.osgi.org/ resources/docs/spec_overview.pdf. TOUCH Center Home Page, http://touch.ncku.edu.tw/touch/. Wacks, K. (2001). The successes and failures of standardization in home systems. In Proceedings of the 2nd IEEE conference on standardization innovation information technology, Boulder, CO., pp. 77–88, Oct. 2001. Weiser, M. (1991). The computer for the 21st century. Scientific American, 265(3), 66–75. Wu, C.-L., Liao, C.-F., & Fu, L.-C. (2007). Service-Oriented Smart-Home Architecture Based on OSGi and Mobile-Agent Technology. In IEEE Transactions on Systems, Man, and Cybernetics, Part C: Applications and Reviews, March 2007.
Contents lists available at SciVerse ScienceDirect
Expert Systems with Applications journal homepage: www.elsevier.com/locate/eswa
OSGi-based smart home architecture for heterogeneous network Sheng-Tzong Cheng, Chi-Hsuan Wang, Gwo-Jiun Horng ⇑ Department of Computer Science and Information Engineering, National Cheng Kung University, Taiwan
a r t i c l e
i n f o
Keywords: OSGi UPnP DPWS Smart home SOA
a b s t r a c t With the development of home network and service applications, different protocols and transmission modes are proposed. There are more digital devices and home appliances which compliance to the protocols. The proposed protocols are different and they are usually unable to communicate with each other; we design and implement a Service-Oriented Smart-Home Architecture to integrate protocols which are popular such as UPnP, Jini, DPWS on OSGi framework and collaborating Tmote, Zigbee and Bluetooth to converge various service oriented applications. Furthermore, with the well-developed Tmote, Zigbee and Bluetooth technology, majority of devices has been developed to support these technologies, we propose three new base drivers to integrate different devices communication protocol on our platform. Additionally, we propose a Service Resolving Bundle to complement the drawbacks of OSGi mechanisms. However, OSGi services with constructs of additional description are stored in our proposed Service Resolving XML (SRXML). Also, the service user may invoke the service of this bundle to get additional information of the aimed services. The architecture utilized with service-oriented mechanisms to accommodate applications which are implemented across different domains and allows the system components to interact with one another. Ó 2012 Elsevier Ltd. All rights reserved.
1. Introduction With the development of networking and Internet technology, there are growing numbers of digital devices and home appliances which support the plug-and-play ability on the home network. The devices and home appliances such as digital camera, television, mobile phone, refrigerator, air conditioner, washing machine and others are developed to comply with different home network communication protocols. The connection of electronic devices is realizing the vision that Mark Weiser described years ago (Weiser, 1991): our environment is filling with networked devices which are in a growing number. More services are expected to be provided in the future home. Currently the home networking technology is still in a middle of development, there are various protocols available to accommodate the communication between devices and appliances such as Universal Plug and Play (UPnP), Java for Intelligent Network (Jini), Devices Profile for Web Services (DPWS), Digital Living Network Alliance (DLNA) and etc. This situation results non-conformity of general available home network applications and in extensibility for users to set up their digital home environment. Many researches have been devoted to the service discovery or delivery protocols with service oriented mechanism including UPnP, Jini, Service Location Protocol (SLP) and Bluetooth SDP. These ⇑ Corresponding author. E-mail address: [email protected] (G.-J. Horng). 0957-4174/$ - see front matter Ó 2012 Elsevier Ltd. All rights reserved. http://dx.doi.org/10.1016/j.eswa.2012.04.077
protocols facilitate us to establish a dynamic connection between services or devices by integrating automatic query mechanism. They are designed to build a heterogeneous network framework to ease the use of services by user from the service providers. Each of these protocols has its own communication mechanism and characteristics. As an example, both UPnP and Jini technology supported devices which have plug-and-play ability, but both of these protocols use different method for service discovery. UPnP uses a special variant of the HTTP protocol for UPnP devices to communicate with control point, but Jini requires a central registry for Jini devices to register with via UDP multicasts using a proprietary protocol (Obiltschnig, 2006). Besides dealing with the communication protocol issue, home network is also unable to avoid the problems of dynamically varying home environment and distributed connection. Since there are mobile devices connected to the home network with distributing, it often happens that the devices were disconnected dynamically, which means that the services configuration in the smart home is usually dynamic. Furthermore, smart home should not only execute the commands which are received from the residents, but also collecting context information actively from environment. With the context information collected, system will infer the current user scenario and makes suitable reaction to provide comfortable environment for resident (Wu, Liao, & Fu, 2007). To deal with the whole operation mentioned, system needs to control and communicate with all the devices distributed in the home network. Therefore designers of the innovative home applications are facing three
S.-T. Cheng et al. / Expert Systems with Applications 39 (2012) 12418–12429
12419
Fig. 3. Service-Oriented interactions.
forming to open standards (Wacks, 2001). Here we propose a service-oriented architecture (SOA) based on OSGi OSGi, collaborate with UPnP, Jini and DPWS with the integration of Bluetooth, Zigbee and Tmote Support.
2. Related work Fig. 1. Conventional Smart Home Architecture.
The Open Services Gateway Initiative OSGi is an independent, non-profit corporation working to define and promote open specifications for the delivery of managed services to networked environments, such as homes and automobiles. These specifications define the OSGi Service Platform, which consists of two pieces: the OSGi framework and a set of standard service definitions. The OSGi framework, which sits on top of a Java virtual machine, is the execution environment for services. The OSGi framework was originally conceived to be used inside restricted environments, such as the set-top box in Fig. 2.
main challenges in this pervasive environment: dynamicity, heterogeneity and distribution. Furthermore, with the well developed Bluetooth technology, majority of digital devices have been developed to support Bluetooth. These devices comprised from different domains such as multimedia, data communication, office appliance and others to fulfill human being living demands. It is easy to see a device which is developed to support Bluetooth, for an example, mobile phone. In the mean time, there is a trend showing that Bluetooth enabled devices have become popular and it is can be saw everywhere in our living environment. Therefore, it is needed to fully utilize this communication capability. Additionally, wireless sensor network such as Zigbee and Tmote are playing more and more important role in smart home nowadays. It is usually needed in a smart home to collect environment data. Furthermore, it can be used to accommodate the controlling of the home appliance. It is a trend to accommodate the extensibility of the wireless sensor network in a smart home. In the light of the requirements mentioned above, a smart home should comply with the emerging computer technologies and appropriately fulfill human requirements. Regarding to the mass potential consumer market, we develop smart home with con-
The framework can be divided in two main elements: (1) A services platform. (2) A deployment infrastructure. A services platform is defined as a software platform that supports the Service Orientation interaction depicted in Fig. 3. This interaction involves three main actors: service providers, service requesters and a service registry, although only the service registry belongs to the services platform. In the Service Orientation interaction, service providers publish service descriptions, and service requesters discover services and bind to the service providers. Publication and discovery are based on a service description.
Fig. 2. OSGi overview.
Fig. 4. Bundle Life-Cycle.
2.1. The OSGi framework
12420
S.-T. Cheng et al. / Expert Systems with Applications 39 (2012) 12418–12429
In the context of OSGi, a service is described as a Java class or interface, the service interface, along with a variable number of attributes, the service properties that are name and value pairs. Service properties allow different service providers that provide services with the same service interface to be differentiated. The service registry allows service providers to be discovered through queries formulated in LDAP syntax. Additionally, notification mechanisms allow service requesters to receive events signaling changes in the service registry; these changes include the publication or retrieval of a particular service. Deployment activities are realized according to a well defined series of states depicted in Fig. 4; these states correspond to the bundle life-cycle. Bundles can be dynamically installed, started, stopped, updated and uninstalled. During the execution, the bundle perform state transition which is controlled through OSGi module management API. The following describe bundle states (http:// en.wikipedia.org/wiki/Service-oriented_architecture, http://publib.boulder.ibm.com/infocenter/ledoc/v6r1/index.jsp?topic=/com. ibm.rcp.tools.doc.appdev/smfbd_concepts_blcycle.html): (1) INSTALLED – the bundle has been successfully installed; (2) UNINSTALLED – the bundle has been successfully uninstalled and no longer exists in the framework; (3) RESOLVED – the bundle is installed, and its dependencies have been met. This state indicates that the bundle is either ready to be started or has stopped; (4) STARTING – a temporary state that the bundle goes through while the bundle is starting; (5) STOPPING – a temporary state that the bundle goes through while the bundle is stopping; 6) ACTIVE the bundle is running. 2.2. Service dependency management Service dependency management includes all the activities necessary to create binding between logical bundles during execution. This includes service publication, discovery, binding and adaptation with respect to changes due to dynamic availability (the arrival or departure) of services that are being used by a bundle during execution. Service dependency management is the key for building applications for the OSGi framework. Unlike code dependencies, service dependencies are not guaranteed, or managed, by the framework; this means that a physical bundle can be activated, even if services required by the logical bundle are not available. Service dependencies can be declared in the manifest file, but currently the OSGi specification indicates that they are declared for information purposes only.
Fig. 5. An OSGi application.
Fig. 5 depicts a typical OSGi application modeled as a series of logical bundles that are connected through the provided and required services. Sensor bundles are connected to physical sensors such as motion detectors, smoke detectors or cameras. A monitor polls the sensors and responds to particular situations for example by sending an e-mail to an administrator or by writing a log. The monitor also uses the services provided by an HTTP server to register a servlet so that management can be done remotely through a web page. In example above, the monitor’s logical bundle uses services provided by other logical bundles to accomplish its task. In this case the monitor bundle is responsible for discovering the services it requires. On the other side, the logical bundles that provide services are responsible for publishing them in the service registry. During execution, the different services exhibit dynamic availability as they are introduced or removed from the execution environment as a consequence of physical bundle deployment activities. It can be supposed, for example, that new sensor bundles can be introduced into the execution environment at any time, without the need of shutting down the system. Logical bundles are responsible for binding to newly arriving services or releasing departing services. Dynamic availability of services requires an application to be capable of dynamic assembly and dynamic adaptation. 2.3. Service components The Service Binder introduces the concept of service component to the OSGi framework. A service component is similar to the concept of a logical bundle but the difference is that multiple service components can be deployed inside a single physical bundle. A service component (see Fig. 6) declares a set of provided service interfaces, and a set of required service interfaces. During execution, an instance of a service component implements the provided services and it is connected to other instances to create an application. Service properties identify the instance and they are used when its services are published in the service registry. Provided and required service interfaces along with service properties represent an external view for the component, and they are a part of the application logic. This external view is implemented by a component implementation that can also provide certain control interfaces and it has some dependencies. Control interfaces implement the inversion of control pattern and they are provided so that the execution environment can manage instance’s lifecycle. Implementation dependencies represent dependencies from the component implementation on resources that
Fig. 6. A component class.
S.-T. Cheng et al. / Expert Systems with Applications 39 (2012) 12418–12429
12421
Fig. 7. The UPnP base driver architecture.
Fig. 8. The UPnP device interfaces.
Fig. 9. An example of Jini with OSGi operation.
are delivered along with the component (such as libraries or binary files) or they represent deployment dependencies.
In order to instantiate UPnP devices, developers must register services implementing the interfaces represented in Fig. 8 and services provided by the org.osgi.compendium bundle. The exporter is registered as ServiceListener (OSGi alliance) with the framework and it automatically exposes on the networks which each UPnP Device service registered with the registration property UPNP_EXPORT (OSGi alliance). The importer listens to the advertisements sent on the networks by external devices and registers with one or more UPnP Device services of the framework. Even if it is not required by the specification, the devices which are imported by the Felix base driver are labeled with the registration property UPNP_IMPORT (Felix).
2.4. Existing smart home networking for OSGi The Fig. 7 shows a simplified component view of the base driver. The driver is composed by two components, the exporter and importer; both using the CyberDomo library, which is a modified version of the library released by the ‘‘CyberLink for Java’’ project (CyberGarage), maintained by the Domoware project (Domoware). The library implements a full UPnP stack. The base driver acts as a bridge between OSGi and the UPnP networks.
12422
S.-T. Cheng et al. / Expert Systems with Applications 39 (2012) 12418–12429
Fig. 10. Global system modularity.
Working with UPnP Device from the OSGi point of view means to operate with services; the discovery, controlling and managing event phases of the UPnP protocol are naturally mapped to the OSGi service layer, which allows publishing, find, bind and notify events. There are some different aspects to work with UPnP in OSGi with respect to other UPnP libraries, due to the basically centralized nature of the OSGi registry opposed to the distributed approach used in UPnP networks; some hints are provided in the section ‘‘Writing UPnP Devices and Control Points’’. Consider the following example, illustrated in Fig. 9: a service that controls a lamp through the X10 protocol registers itself, and its Jini compliance, in the OSGi framework. The Jini Driver detects the presence of the service and exports it to a lookup service in the Jini network. If a Jini client wants to use the lamp service, it contacts the Jini LUS and retrieves the lamp service proxy. Next, the client sends commands via the proxy to the original lamp service, which forwards them to the lamp device. Note that this is the usual process for the Jini client and it unawares that the Jini lamp service was exported from the OSGi framework. Our DPWS Base Driver is designed to gain modularity (Fig. 10) so that it is capable to deal with the use case variety. Thus, only a precise set of bundles is useful for every use case. Bundles can be installed on-demand thanks to the capabilities of the underlying OSGi platform. DPWS defines the interaction between devices and clients (a.k.a. control points). Three main technical use cases are defined in the next sections: the generic network control point use case, the specific application client use case, and the specific DPWS device use case. In this work, our major contributions are (1) Transcode signal mode in integrated heterogeneous network to increase extendibility and enable communication for more networks. (2) Add task controller to increase system performance and enable resource assignment. (3) Add three kinds of bundle base driver (Bluetooth, Zigbee, T-mote) on OSGi platform. 3. Home application design
telecommunication operators, service providers, manufacturers and software vendors. They come along with market expectations for enriched multimedia activities, home surveillance and home care services for the disabled or elderly people (Aiello, 2006). As a result, there are lots of hard challenges for the achievement of these envisioned scenarios in the home network. But generally, these challenges are emphasized by the openness of the home network environment: (1) Dynamicity due to device availability, device context, user location and activity. (2) Distribution due to the natural location of devices in the home. (3) Heterogeneity due to hardware, software and protocol variety laid by the market evolution. (4) Embedded constraints due to device low cost drawn by the consumer electronics market. In order to face these challenges, application flexibility and development simplicity are demanded in home network. Service Oriented Architecture and component approach in the software development meet some of the requirements. The technological specification of the platform achieves the needs of flexibility and the device availability management is simplified. We have focused the effort and contribute at the design of our service oriented drivers and its implementation relying on the concept of ‘‘service platform’’. This architecture further answers the needs for managing distributed aspects and protocol heterogeneity in a transparent way for the developer while keeping the implied overhead below reasonable barriers. 3.2. Service Oriented Computing and local networks Service Oriented Computing consists of modeling an application into logical entities which are providing functionalities and there are other entities which are using those functionalities. A piece of functionality which is able to be invoked is called a service. The description of a set of operations is called a service interface. A logical entity which is providing a service is called service provider and an entity which is using a service is called service user. The complete chart of the Service Oriented Architecture includes an entity which is called service registry, which is responsible for storing the description of available service providers (Fig. 15). Service provider first publishes their description in the service registry. The description contains service interface and specific distinguishing properties of the service provider. When a service user tries to request a service, it will actively request for the service list from the service registry, this activity is called active discovery mode. There is another passive discovery mode which means the service user listens to service registration events, but this mode is only implemented when the service user knew the needed service interface and specific properties in advance. The advantages of Service Oriented Computing are: (1) Abstraction: The organization of third-party entities is considered as a service composition. Home devices are represented as black boxes. (2) Loose coupling: Providers and clients only share a service interface. Clients are independent from provider implementations. Substitutability is stressed by service discovery filters that consist of a simple interface name and descriptive properties. (3) Separate administration: Composed entities have distinct lifecycles. Consequently, Service Orientation brings the abstraction needed in the composition of heterogeneous device features and the flexibility needed for the application resiliency to the home network dynamics.
3.1. Home application requirements
3.3. Component orientation in service oriented applications
In the development of the smart home, people proposed many scenario and use cases to provide future vision for us. These scenarios and use cases are mostly done by researchers such as
With the property of being complimentary of Service Orientation, component orientation is also needed in the home application design. This approach models the applications into a high-level
12423
S.-T. Cheng et al. / Expert Systems with Applications 39 (2012) 12418–12429
Fig. 11. Platform-centric architecture.
service composition whereas the implementation of every identified network entity follows the approach. Advantages of the component approach are: (1) Code structuring: every networked entity is implemented as a logical code unit. (2) Separation of the business logic and the nonfunctional aspects: service distribution, service dynamicity and service (protocol) heterogeneity have to be managed transparently for the business developer. Containers are responsible for the management of these non-functional aspects. (3) Inversion of Control: The lifecycle of the component is managed outside of the component and its inner business logic. The control of this lifecycle is given to the containers. As a conclusion, Component Orientation approach leads us to accommodate application modularity to every involved entity in the whole application. It makes the management of complex non-functional aspects transparent to the business developer while the whole application composition is left to the administrator. As Thierry Coupaye et al. write in Collet, Coupaye, Chang, Seinturier, and Dufrêne (2007), component approaches are used in a pre-facto integration mode where all the components have to obey the same component model. On the other hand, Service Orientation is needed in a post-facto integration mode where every software entity has to be integrated just as it is with its own behavior.
won’t provide access to their devices to any operator or device (for safety, security and obviously business considerations). Devices are dynamic, based on various protocols and provide information in heterogeneous ways. We believe that, in order to realize the vision of sophisticated pervasive services in the home, it is necessary to build an open computing framework to run user-related services on home gateways. Such framework (Bottaro, Gérodolle, & Lalanda, 2007) should abstract the developer from low level details related, in particular, to service and communication technologies. 4.2. The service platform concept
4. OSGi-based smart home mechanism
In this vision (Bottaro, Simon1, Seyvoz, & Gérodolle, 2008), the application design is modular thanks to the component approach of the platform and every device feature, i.e. every service, is reified on the platform. In order to enable application components to dynamically compose those services, they are registered in a common service registry on the platform. We consider that the service platform is the smart dynamic receptacle of pervasive entities. This adaptable receptacle turns pervasive software composition into the composition of uniform service components. The main role of the platform is to adapt to the environment in locally representing all the relevant external entities with their specific context on the platform.
4.1. The platform-centric vision
5. OSGi-based smart home architecture
As previously introduced, we are working on an open serviceoriented computing architecture for the home. This architecture comprises network-enabled devices and computing platforms connected through field buses. Computing platforms often play the role of network gateways. Such gateways are already presented in many houses (telecommunication Internet gateways, TV connected set-top-boxes or utility service gateways) and it is likely that future homes will become host several, heterogeneous computing platforms (Fig. 11). Gateways provide the resources needed to run higher level services which are making use of the connected devices. The purpose is to coordinate multiple devices and to ensure natural, sometimes invisible, interactions with the users. These interactions are obviously directed by high level goals that can be set by the user or by Internet services to which the user has subscribed. Some electronic devices can be exclusively connected to a given gateway. For instance, a home control gateway can coordinate the behaviors of specific devices like shutters or heaters. This approach meets proven market constraints which state that most manufacturers
With the capabilities of OSGi, home applications can be maintained under a generic environment which comprising several heterogeneous frameworks. We now discuss how OSGi accommodate
Export
Service Provider
Import
Service API
Service User
Fig. 12. Service Oriented Architecture in OSGi.
12424
S.-T. Cheng et al. / Expert Systems with Applications 39 (2012) 12418–12429
this heterogeneous framework to allow the maintenance of the applications from different domain. OSGi platform (Alliance, 2005) is one of the main standard execution environments which allowing application reconfiguration at runtime. The model is designed based on Service Oriented Architecture which is relying on a service registry and service event mechanism. Therefore, the service oriented mechanism is implemented in OSGi platform in the following pattern. Each of the service provider, service consumer and service interface are concluded in different bundles separately (Figs. 12 and 13). Firstly, the bundles will import service API package from the service API bundle to gain the communication capability with OSGi environment. Secondly, regard to the Fig. 13, the functional component in service provider bundle will first register itself with the service registry bundle. When service user bundle online, the relevant functional component will request service information from service registry bundle. After the service registry bundle reply, then only service user bundle able to bind with the relevant service bundle (Describe how the bundles work together reference to the picture). This environment enables the bundles to be installed and uninstalled at runtime and the bundles are able to gain communication ability with the OSGi environment through the service API.
Bundles
Service provider
Functional Component
Service User
Service Registry
Database
1. Register
3. Reply Binds 2. Request
Service Provider
Service Consumer
Fig. 13. Service Oriented Architecture in OSGi.
5.1. System architecture Fig. 14 depicts our OSGi home network architecture. The OSGi gateway serves as the central coordination point for managing the home network, spanning multiple heterogeneous communication technologies. The OSGi specifications enable service providers and application developers to deploy and to manage in-home network services and devices. Because OSGi specifies only the application programming interface (API) instead of the underlying implementation, OSGi gateway is able to be both platform- and application-independent. This independence gives application developers and service deploying considerable operating and design freedom to distinguish their offerings. Open specifications promote application development that increases interoperability and reduces the time to market for new services. Other OSGi benefits include multiple service support, security, service collaboration, and multiple network support. It is the last benefit that come of particular interest here, and we explore it in greater detail later. The OSGi specification includes a framework, resembling an embedded application service for dynamically loading and managing software components, bundles. These bundles can be dynamically instantiated by the framework to implement particular services. Additional framework components include HTTP support services, logging functionality, and the Device Access Specification (DAS) Services Gateway Initiative. The DAS allows multiple devices to be discovered and their services advertised, by the framework so that they can be made available to other devices, services and applications. With the modular architecture mentioned above, we are able to integrate the devices and services from different domain into our own OSGi framework. The modular design enables the remote devices and services to appear as local entities on our OSGi framework. When a client wants to request for these services, they first request the relevant service bundle on our OSGi framework. Next, the client sends commands via the bundle which forward them to the services. On the other hand, the devices and services on our OSGi framework are able to appear as valid entities in other domain if these devices and services are compliant with the specific domain. The base drivers detect the presence of the service from our OSGi
Fig. 14. Our OSGi-based smart home network architecture.
S.-T. Cheng et al. / Expert Systems with Applications 39 (2012) 12418–12429
12425
Fig. 16. Tmote base driver architecture. Fig. 15. Bluetooth base driver architecture.
service registry and export it to the relevant domain Control Point. This will make the exported service appears as a local entities in the point of view of other clients which are in the same domain. If a client wants to use service, it will contacts the relevant control point and retrieves the service proxy. Next, the client sends commands via the proxy to the original service, and then the proxy will forward the commands to the original service entity. 5.2. Bluetooth base driver We have been developing a Bluetooth base driver to ease the usage of Bluetooth devices in OSGi environment. This Bluetooth base driver is composed by two parts: Importer and Exporter. Importer is responsible to listen to the advertisements on the networks by the Bluetooth devices and services. Then it will import all the discovered services and devices into OSGi environment, making them appear as valid OSGi entities and fully accessible by other OSGi entities (Fig. 15). On the other hand, Exporter is registered as ServiceListener with the OSGi framework and it responsible to export the OSGi entities which is compliant to the Bluetooth profile to the Bluetooth environment automatically, making them appear as virtual Bluetooth services and devices and fully accessible by other Bluetooth entities. Even it is not required by the OSGi specification, the imported and exported devices and services are registered with the registration property BT_IMPORT and BT_EXPORT correspond to their situation. In order for Bluetooth devices to communicate properly, we have been developing this Bluetooth base driver with conform to the Bluetooth specification. The Bluetooth specification, like any other spec, defines the standard that a Bluetooth device should adhere to, as well as the rules which are needed to be enforced when communicating. The Bluetooth protocol stack and profiles together comprise the Bluetooth specification.
On the other hand, Exporter is registered as ServiceListener with the OSGi framework and it responsible to export the OSGi entities which is compliant to the Tmote profile to the Tmote environment automatically, making them appear as virtual Tmote services and devices and full accessible by other Tmote entities. Even it is not required by the OSGi specification, the imported and exported devices and services are registered with the registration property TMOTE_IMPORT and TMOTE_EXPORT correspond to their situation. In order for Tmote devices to communicate properly, we have been developing this Tmote base driver with conform to the Tmote specification. The Tmote specification, like any other spec, defines the standard that a Tmote device should adhere to, as well as the rules which are needed to be enforced when communicating. The Tmote protocol stack and profiles together comprise the Tmote specification. 5.4. Zigbee base driver We have been developing a Zigbee base driver to ease the usage of Zigbee devices in OSGi environment. This Zigbee base driver is composed by two parts: Importer and Exporter. Importer is responsible to listen to the advertisements on the Zigbee networks by the devices and services. Then it will import all the discovered services and devices into OSGi environment, making them appear
5.3. Tmote base driver We have been developing a Tmote base driver to ease the usage of Tmote devices in OSGi environment. This Tmote base driver is composed by two parts: Importer and Exporter. Importer is responsible to listen to the advertisements on the Tmote networks by the devices and services. Then it will import all the discovered services and devices into OSGi environment, making them appear as valid OSGi entities and fully accessible by other OSGi entities (Fig. 16).
Fig. 17. Zigbee base driver architecture.
12426
S.-T. Cheng et al. / Expert Systems with Applications 39 (2012) 12418–12429
as valid OSGi entities and fully accessible by other OSGi entities (Fig. 17). On the other hand, Exporter is registered as ServiceListener with the OSGi framework and it responsible to export the OSGi entities which is compliant to the Zigbee profile to the Zigbee environment automatically, making them appear as virtual Zigbee services and devices and full accessible by other Zigbee entities. Even it is not required by the OSGi specification, the imported and exported devices and services are registered with the registration property ZIGBEE_IMPORT and ZIGBEE_EXPORT correspond to their situation. In order for Zigbee devices to communicate properly, we have been developing this Zigbee base driver with conform to the Zigbee specification. The Zigbee specification, like any other spec, defines the standard that a Zigbee device should adhere to, as well as the rules which are needed to be enforced when communicating. The Zigbee protocol stack and profiles together comprise the Zigbee specification.
6. Analysis and discussion In this section, we analyze system performance under three different models. We assumed that there are n clients requesting service at the same time; each service involves m Service Providers (SPs) of y Control Points (CPs) and costs each provider p computation time units. Each service has to interact with the CP with j messages, and it costs h network traffic units to transmit one message, each CP has to interact with the server with z messages and it costs e network traffic units to transmit one message. Each client sends request to the server and costs i network traffic units to transmit one message. To perform a service invoke task in a conventional smart home architecture mentioned above, each client must send service request to the server and then the server interacts with these y CPs by sending z messages to accomplish theses service requests. Each CP then sends j messages to the SP to invoke the requested services. After receiving data from different SP passed by CPs, the server processes these data, integrates them and returns the final results to the clients. Analysis is shown in Table 1, in which CP stands for ‘‘Control Point’’ and SP stands for ‘‘Service Provider’’, (⁄n), (⁄y) and (⁄m) represent the possible numbers of the associated entities and 1 n in the CP and SP columns means each of them accepts 1 n service requests, thus changing the workload of its network traffic and computation. As for the performance analysis of our architecture, clients query the service directory first to retrieve information about SP and obtain the service reference of the corresponding SP. Then the client interacts with m SPs remotely by sending j messages to each. When a client receives data that are returned from m
SPs, it processes them and costing q computation time units for each and then integrates them. Performance analysis is shown in Table 2. Table 3 shows the performance analysis of the P2P SOA with MA (Wu, Liao, & Fu, 2007). First, the clients query the service directory to retrieve information about SPs, and then create Mobile Agents (MAs) embedded with interaction logic based on service requirements. After that, every client sends its MA to SP, and since MA represents the client, the SP is able to interact with the MA locally and directly. Observing the computation load part in these three tables, the computation loads are the same comparing our architecture with the P2P SOA with MA model. It is a bit heavier for the computation load in the conventional architecture because the server needs to process and integrates data from different CPs. In the P2P SOA with MA model, the server load is distributed to SPs. Although this kind of distribution seems effective, it is not suitable for SPs which is lack of computation power. Based on our architecture, the server computation load is distributed among n clients and this kind of distribution seems fair. As for the network part, the clients handle more traffic in our architecture because they need to get service reference from the supplemental bundle additionally. It is not easy to compare network traffic in our architecture and in P2P SOA with MA model because there are different types of network traffic units. Note that our architecture which is utilized with the base driver helps to pass by the interaction between the client and CPs and hence the decrease of the server network traffic comparing with the conventional smart home architecture. Comparing network traffic of the client of our architecture with other model, the total traffic of the client of our model is greater because of getting service reference. But it provides a facility in the architecture which the other does not.
7. System evaluation To implement our proposal, we selected the open source OSGi Service Platform, Knopflerfish version 2.0.5 which led and maintained by Makewave (Knopflerfish OSGi). It is an open software implementation of the OSGi framework. We set up the framework and implemented it at the National Cheng Kung University Aspire Home for Quality Life. The Jini base driver is supported since OSGi specification version R3 and UPnP base driver is adopted. We used Jini version 1.2.1 (Community Resources for Jini), Odonata DPWS base driver 1.0.6 (InfraGforge), Domoware UPnP Base Driver version 3.0.2 and Control Points and Light devices correspond to DPWS, Jini and UPnP have been implemented on the prototype. Also, we developed the Control Point which is managed in the base
Table 1 Performance analysis of conventional smart home architecture. Conventional architecture
Network traffic ⁄
Computation load
Scenario
Client ( n)
Server
Client request server Server request CP CP request SP SP start service SP return data CP return data Server processes data Server integrates data Server returns results
i
i ⁄n e⁄z⁄y⁄n
Total
⁄
CP ( y) ln e⁄z e⁄z⁄n h⁄j⁄m h⁄j⁄m⁄n
⁄
SP( m) l n
Server
SP(⁄m) l n
h⁄j h⁄j⁄n p p ⁄n
e⁄z⁄y⁄n
h⁄j⁄m n⁄j⁄m⁄n e⁄z e⁄z⁄n
h⁄j h⁄j⁄n q⁄y⁄n q ⁄n
i ⁄n
i ⁄
2⁄n ⁄(i + e⁄z⁄y) 2i 2⁄(2⁄n⁄(i + e⁄z⁄y) + h⁄j⁄m⁄n⁄(y + 1))
2⁄n ⁄(e⁄z + h⁄j⁄m)
2⁄h⁄j⁄n
q⁄n⁄(l + y) n⁄(q⁄(y + l) + p⁄m)
p p ⁄n
12427
S.-T. Cheng et al. / Expert Systems with Applications 39 (2012) 12418–12429 Table 2 Performance analysis of our proposed architecture. Our architecture Scenario
Network traffic ⁄
Client ( n)
Client queries service registry Client queries service reference Client requests SP SP start service SP return data Client processes data Client integrates information
i i i⁄j⁄m
Total
2⁄i⁄(l + j⁄m) 2⁄i⁄n⁄(3 + 2⁄j⁄m)
Computation load Service registry
Supplemen bundle
⁄
Client (⁄n)
SP( m) l n
SP(⁄m) l n
⁄
in i⁄n i⁄j i⁄j⁄n p p ⁄n
i⁄j⁄m
i⁄j i⁄j⁄n q⁄m q i ⁄n
i⁄n
2⁄(i⁄j i⁄j⁄n)
q⁄(l + m) n⁄(q + m⁄(p + q))
p p ⁄n
Table 3 Performance analysis P2P SOA with MA. P2PSOA with MA
Network traffic
Senario
Client (⁄n)
Computation load Service directory
SP(⁄m) l n
Client (⁄n)
SP(⁄m) l n
⁄
Client queries service directory Client sends MAtoSP SP start service SP process data SP returns MA with data Client integrates results
i k
in
i+k
(i + k) (i + k)⁄n
Total
2 (i + k) i ⁄n 3⁄i⁄n + i⁄m⁄n + 2⁄k⁄m⁄n + 2⁄k⁄n
(i + 2k) (i + 2k)⁄n
k k⁄n p p ⁄n q q ⁄n q q n⁄(q + m⁄(p + q))
(p + q) (p + q)⁄n
Fig. 18. Performance evaluations of different interaction models.
drivers of Bluetooth, Tmote and Zigbee. We connected the Tmote audio player, Tmote coffee machine and Zigbee light devices in the Aspire Home and all the connected devices are controlled by Bluetooth enabled hand phone through a media center as graphical user interface. While every device connected to the different network they belong to, the corresponding base driver bundle will automatically import the devices from each different network into OSGi framework. As a result, we are able to inspect the attendances of the devices from different network domain on the OSGi service registry. We implemented a scenario that shows us the view of the power of the collaboration of different network. In this scenario, we assume that John has signed a maintenance contract for his OSGi residential gateway. One day, John comes back home from work and starts using his Bluetooth enabled mobile phone to control the devices in his house. First he switches on the light of the house once he enters the door. He then opens his media center and sits down to have a break in the living room while he playing on a movie. In the meantime, John controls the coffee machine to make a cup of coffee. After that John sitting in front of the media center and he turns off the light of the house into movie mode, while he enjoying the movie and his coffee. The scenario above includes lots of service registration, discovery and invocation in our OSGi framework. Firstly, when John
Fig. 19. Smart home platform offered by TOUCH center.
comes back from work, his Bluetooth enabled hand phone automatically connect to his home’s Bluetooth network. The Bluetooth base driver on our OSGi framework inspects the attendance of the phone, detects the Bluetooth identify number and automatically imports it into our OSGi framework. Since then the house knew that the phone will be the remote control for the devices. Before John switch on the light through his phone, the Bluetooth base driver converts the light devices into virtual Bluetooth light devices and allow John to control them. Once John sitting down in the living room and plays a movie on the media center, the OSGi framework receives the control signal forwarded from the Bluetooth base driver to the media center whereas an OSGi entity and allowing the phone to be remote control. The Bluetooth Enabled phone discovers the attendance of Tmote coffee machine through the service registry of OSGi framework. This allows John to invoke the machine to make a coffee. Then, The Tmote coffee machine receives control signal by Tmote base driver whereas a proxy which is forwarding the signal sent by the Bluetooth Enabled phone. Finally, John controls the light devices to turn to the movie mode to provide a comfortable movie watching environment. This scenario may lead you to
12428
S.-T. Cheng et al. / Expert Systems with Applications 39 (2012) 12418–12429
Fig. 20. Home control center interface on PDA, Zeus.
understand how Tmote, Zigbee and Bluetooth act in our OSGi framework. To study the performance of different interaction models (conventional smart home architecture and our architecture), we conducted experiments with our prototype implementations. We used a task controller to initialize the execution of a new task and to measure the turnaround time of execution in each experiment. A task is defined as a sequence of executable procedures on devices distributed over the network. In our experiment, the OSGi platforms have to collect data from devices and integrate the data as well as to perform inferring to produce the result upon receiving new task. Our experiments are described below. In the first scenario (conventional smart home architecture), there is a single OSGi platform connected with five devices through CPs from different domain via Ethernet locally as we shown in Fig. 1: Tmote device, Zigbee device, Bluetooth device, DPWS device and UPnP device. Each task is defined as sequentially gathering data from five devices and then performs integrating and reasoning procedures in OSGi platform. The time to integrate and reasoning and the data retrieval latency are both set as 100ms. In this work, we explained the different between conventional smart home and our integrated heterogeneous network (UPnP, Jin, Service Location Protocol (SLP) and Bluetooth SDP etc.) regard to communication protocol interfaces, which are built between corresponded protocol transcoding services. With protocol transcoding services we can perform data communication which is including data sending and receiving, this capability increases the extendibility of heterogeneous network. Fig. 18 shows the experiment results. Compared to conventional smart home architecture, the turnaround time is decreased drastically with our architecture. The performance results are gained from the direct interaction between client and the proxy of service provider and the decreased number of interaction between client and server. Because of the services are invoked locally in our architecture, most of the costs come from the data transferring latency. Consequently, the experiment result shows us our architecture helps to reduce the task execution by local execution of services. This work demonstrates implementing the system in a realistic smart home, a platform offered by the TOUCH center (TOUCH Center Home) as show in Fig. 19. Additionally, a user living in the smart house was emulated. In the emulation experiment, the system runs from 12:00 AM to 11:59 PM. The experiment was repeated for one week without pre-designing any scenarios before emulation. Users randomly generated actions using a PDA (Fig. 20) and media center based on their own preferences.
8. Conclusions The device and service discovery mechanisms of OSGi enable the creation of advanced home networking services. As illustrated in the preceding usage scenario, OSGi can serve as an effective bridge across disparate networking technologies, making new device interactions possible and leading to services within the home that can fully leverage the growing diversity of devices and better serve the needs of end users. The OSGi platform allows third-party application developers to quickly and easily develop new in-home network services that can incorporate a multitude of device technologies. Device and service discovery techniques within OSGi help to integrate otherwise isolated device technologies, allowing compound cross-technology services to be delivered within the home by multiple vendors. Also, because OSGi specifications are hardware-independent, they can be widely deployed on a variety of hardware and software platforms, unconstrained by the multiple device types in the home. Finally, OSGi specifications define service gateways, not simple routers or bridges. This allows intelligent end-user services, not just simple network connections, to be created and managed within the home network. Moreover, OSGi enables remote service management by third parties. This capability creates opportunities for service packages to be developed and offered to end users. Such service packages enable a service provider to assume all responsibility for provisioning, configuring, managing, and ultimately delivering home network services to subscribers. Discovery techniques allow these third parties to tailor services based on dynamic configurations of home networking elements, intelligently responding to the presence or absence of certain devices within the home. This effectively reduces the complexity seen by the end user, increases the flexibility of service offerings, and enables more rapid deployment of home networking services. References Aiello, M. (2006). The Role of Web Service at Home. In Advanced international conference on telecommunications (AICT/ICIW), Guadeloupe, French Caribbean, February 2006. Bottaro, A., Gérodolle, A., & Lalanda, P. (2007). Pervasive Service Composition in the Home Network. In: 21st IEEE International Conference on Advanced Information Networking and Applications, Canada, May 2007. Bottaro, A., Simon1, E., Seyvoz, S., & Gérodolle, A. (2008). Dynamic Web Service on a Home Service Platform. In 22nd International conference on advanced information networking and applications, March 2008. Collet, P. Coupaye, T., Chang, H., Seinturier, L., & Dufrêne, G. (2007). Components and Services: A Marriage of Reason, Technical, Report I3S/RR-2007-17-FR, May 2007. The Community Resources for Jini Technology. http://www.jini.org/. CyberGarage. http://www.cybergarage.org/net/upnp/java/index.html.
S.-T. Cheng et al. / Expert Systems with Applications 39 (2012) 12418–12429 Domoware. http:// domoware.isti.cnr.it/. Felix. http://svn.apache.org/viewvc/felix/trunk/upnp/basedriver/src/ main/java/ org/apache/felix/upnp/basedriver/util/Constants.java?view=markup. InfraGforge: Amigo. http://gforge.inria.fr/frs/?group_id=160&release_id=1804. Knopflerfish OSGi. http://www.knopflerfish.org/. Obiltschnig, G. (2006). Automatic Configuration and Service Discovery for Networked Smart Devices. In Electronica Embedded Conference Munich, 2006. OSGi Alliance. (2005). OSGi Service Platform Core Specification Release 4, October 2005. OSGi alliance. Available:http://www.osgi.org/javadoc/r4/org/osgi/framework/Service Listener.html. OSGi alliance. Available: http://www.osgi.org/javadoc/r4/org/osgi/service/upnp/ UPnPDevice.html#UPNP_EXPORT.
12429
OSGi alliance. Available: http://www.osgi.org. Open Services Gateway Initiative, Device Access Specification, http://www.osgi.org/ resources/docs/spec_overview.pdf. TOUCH Center Home Page, http://touch.ncku.edu.tw/touch/. Wacks, K. (2001). The successes and failures of standardization in home systems. In Proceedings of the 2nd IEEE conference on standardization innovation information technology, Boulder, CO., pp. 77–88, Oct. 2001. Weiser, M. (1991). The computer for the 21st century. Scientific American, 265(3), 66–75. Wu, C.-L., Liao, C.-F., & Fu, L.-C. (2007). Service-Oriented Smart-Home Architecture Based on OSGi and Mobile-Agent Technology. In IEEE Transactions on Systems, Man, and Cybernetics, Part C: Applications and Reviews, March 2007.