- Email: [email protected]
Integrating service discovery technologies in OSGi platform
Computer Standards & Interfaces 33 (2011) 271–279
Contents lists available at ScienceDirect
Computer Standards & Interfaces j o u r n a l h o m e p a g e : w w w. e l s ev i e r. c o m / l o c a t e / c s i
Integrating service discovery technologies in OSGi platform☆ Min-Xiou Chen a,⁎, Tze-Chin Tzeng b a b
Department of Computer Science and Information Engineering, National Dong Hwa University, 1, Sec. 2, DaHsueh Rd., Shou-Feng, Hualien, Taiwan, ROC Department of Computer Science and Information Engineering, ChungHua University, 707, Sec.2, WuFu Rd., Hsinchu, Taiwan, ROC
a r t i c l e
i n f o
Article history: Received 1 February 2009 Received in revised form 25 December 2009 Accepted 25 May 2010 Available online 15 June 2010 Keywords: Home network Open Service Gateway Initiative Service Location Protocol Session Initiation Protocol Universal Plug and Play
a b s t r a c t This paper describes the service discovery and interaction for home network devices using heterogeneous standards and protocols. OSGi was proposed to allow several kinds of services coming from different providers to be loaded and run on a gateway. We present a residential gateway based on the OSGi architecture for a smart home network. We combine the SLP SA/DA, the UPnP control point and the SIP UA into the gateway to achieve automated device discovery, registry, and management. Application examples are introduced and the implementation results show that our gateway can provide automatic heterogeneous service or device discovery, registry, and management. © 2010 Elsevier B.V. All rights reserved.
1. Introduction In the past decade, communication technology has undergone a tremendous change. Due to the fast and prosperous advancement of online communication technologies, network service can greatly facilitate human daily life. With the rapid expansion of the Internet and the availability of communication technologies, networked home appliances are proliferating at an accelerated pace. For example, more commonplace home appliances are being interconnected with the Internet. Various network services and multimedia services are available throughout the network. Through the network, users can remote access and control over home electrical appliances from office. With the number of networked devices or services within the home, an efficient interconnection protocol and management platform has become crucial research work. For a service consumer, it is difficult to have a complete overview of these services and their availability. These devices produced by different manufacturers have different communication protocols. The dynamics of network devices and services make this process even more complex. Finding the available network service and devices becomes an important issue for constructing a home network. The service discovery mechanism was proposed to support the user in finding available network services or devices. Therefore, the service consumer can find or access network devices or services through the network that are capable of interacting with
☆ This work was supported by the National Science Council of Taiwan, R.O.C. under Grant NSC95-2221-E-216-039, NSC96-2221-E-216-010, and NSC97-221-E-259-036. ⁎ Corresponding author. E-mail addresses: [email protected] (M.-X. Chen), [email protected] (T.-C. Tzeng). 0920-5489/$ – see front matter © 2010 Elsevier B.V. All rights reserved. doi:10.1016/j.csi.2010.05.004
each other using the service discovery mechanism. Numerous protocols, middleware, and standards, such as JXTA [1], UPnP [2], SLP [3,4], and SIP [5], have proposed for interconnection or discovery with these home networked devices. A lot of researches implement a residential gateway based on the OSGi plan to interconnect or discover heterogeneous network devices or services. OSGi (Open Service Gateway Initiative) [6] defines open specifications and standards for the delivery of managed services to networked environments. It is an industry plan for a standard way to connect network devices such as home appliances or network services. The OSGi framework allows several kinds of services coming from different providers to be loaded and run on a service gateway. The OSGi platform can serve as the central coordinating point for managing the home network, spanning multiple heterogeneous communication technologies. Although, the OSGi platform can serve as the central coordinating point for spanning multiple heterogeneous communication technologies, the devices still cannot discover the UPnP services and devices using SLP or JXTA. It is because that these service discovery standards and protocols are mostly proprietary and do not operate easily with other networks. This paper proposes and implements a way to bind several home network protocols, making the devices or services of one network discoverable to others. We present a residential gateway based on the OSGi architecture for a smart home network. To achieve automated heterogeneous devices discovery, registry and management, the SLP (Service Location Protocol) SA/DA component, the UPnP (Universal Plug and Play) control point and the SIP (Session Initiation Protocol) UA, will be integrated into the OSGi platform. We also integrate the SLP UA, UPnP control interface into the SIP UA. Based on our proposed architecture, the user can easily discover and access the UPnP devices and service using the SLP UA and SIP UA.
272
M.-X. Chen, T.-C. Tzeng / Computer Standards & Interfaces 33 (2011) 271–279
The remainder of this paper is organized as follows. The related literatures on session discovery are discussed in Section 2. Section 3 proposes the OSGi-based control architecture, as well as how the SLP SA/DA, the UPnP control point and the SIP UA can be combined into the gateway. The implementation architecture and the implementation results from our architecture are described in Section 4. Finally, we draw our conclusions and some future works in Section 5.
interaction model with the OSGi platforms to provide the ability to interconnect networks with different technologies. In [17], Ai et al. improve the OSGi platform to support automotive telematics. However, the service discovery mechanism was not considered in their architecture.
3. System architecture 2. Related works 3.1. Related protocols The aim of ubiquitous computing is to integrate computer devices and network services into daily human life. The user can access any telecom or datacom service as voice, video or data, anywhere at any time with any devices. Therefore, this is a desirable service if a user can change the communication device adaptively, according to his surrounding environment, during a communication session. In [7], Schulzrinne et al. proposed an intelligence system, that provides a ubiquitous computing environment in the home network. To provide ubiquitous computing a lot of techniques and services should be integrated into the intelligence system. The location sensing service is the key component used to locate the user's position. Based on the correct position information, the intelligence system can provide available services or devices to the user. The Bluetooth technique, GPS, and sensor network can be used in the location sensing services. The resource discovery and control servers provide the user with available service or devices for controlling these services and devices. The SLP and SIP were introduced to provide service discovery and control. The access control system allows the user to remote control home appliances. Based on the architecture proposed in [7], Shacham et al. proposed the detail implementation in [8]. In [8], the SLP was used to search for service, with SIP used to control the network devices. To provide session mobility over multiple devices, the “Virtual Device” concept or a Multi-Device System (MDS) was introduced. Two different modes were involved in their system. In the Mobile Node Control (MNC) mode, the user agent transfers and retrieves the session using a Third Party Call Control (3PCC) mechanism. Session Handoff (SH) mode uses REFER method, which is a SIP extension method defined in RFC 3515, to establish a SIP session with each device. To efficiently manage the session over multiple devices, the Multi-Device System Manager (MDSM) was introduced. We also proposed a mechanism, referred to as “Split a SIP session over multiple devices (SSIP)” [9], to provide split session service. Some improvements were involved in our mechanism to obtain the ability to split a session. The extension header “Mobility” was introduced to improve the REFER method and make it transparent to the remote party. The “Association” record was used to terminate all split sessions separately when a session was split over multiple devices. Moreover, in order to facilitate transferring, splitting and retrieving a session over multiple devices, we proposed a complete mechanism, referred to as “Session Integration Service” [10]. In order to provide facility session mobility, three new agents, session manager, session user, and free node were introduced in our mechanism. The session manager transformation (SMT) procedure and the session manager acquirement (SMA) procedure were introduced to provide much more flexibility in session mobility. To integrate the service discovery service in the home network, Dobrev et al. introduced the OSGi platform to solve the problem in [11]. Based on the Bridge bundle, the UPnP services and Jini services were working as the services in the OSGi platform. Thus, the OSGi services and the UPnP devices can be interconnected. In [12,13], the authors proposed a solution that uses the SIP and the Bridge bundle of the OSGi platform to interconnect and access heterogeneous network devices or services. [14] proposed a solution to provide service discovery by SIP. In [15], the OSGi platform was improved to support the ALL-IPv6 environments. In [16], Wu et al. proposed a P2P
3.1.1. Service Location Protocol The Service Location Protocol (SLP), defined by IETF, is an Internet standard network protocol that supports the user in finding the existence, location and configuration of available network services. This protocol enables service registration and simplifies any subsequent search for services. SLP is used by devices to announce services or discover services on an unmanaged network. Each service can be located using the Uniform Resources Locators (URLs). The URL can have an IP address or the domain name, and the service type. The service types can be classified into a particular service type or abstract service type. The well known network services, such as http, ftp, and so on, are belonged to a particular service type. The abstract service type is associated with a variety of different service agents, such as a printer, webcam and so on. To efficiently manage and discover services three network components are involved in the SLP architecture. They are Service Agents (SAs), Directory Agents (DAs) and User Agents (UAs). The SLP SA is a device that provides one or more services in a network. The SLP SA can advertise services to the SLP DA or provide service information to the SLP UA when the desired service matched. The SLP DA is a process that manages the services registered from the SLP SAs, or applications stored in DA's local database. The SLP DA can provide service information when the SLP UA sends its discovery request. The SLP UA is a software entity used to search for network services. Without any network service or network host names, the users can find the available services using only a description of the desired service. The SLP UA sends a request with the description to the SLP SA or the SLP DA, and the SLP SA or the SLP DA will then return the response with the URL for the desired service. SLP can support the network scale from small, unmanaged networks to large enterprise networks. All the network devices and services can be grouped into several scopes. Each device or service should be in one or more scopes. In SLP, the scope is a set of network devices or services. A scope can be described as a simple string and denoted as the domain name in a campus network or the department name in an enterprise network. The SLP UA can only search the network devices or services from its scope. SLP allows the administrators of a scope to organize users, network devices and servers into administrative groups. In SLP, the SLP UA can directly send search requests to the SLP SA. In this case, the SLP UA sends a request by multicasting. When the SLP SA receives a request that it can service, the SLP SA will reply with a unicast message containing the service's location to the SLP UA. This kind of approach is suitable for small, unmanaged networks. In larger networks, as the number of SLP SAs grows, it becomes necessary to partition these devices into several scopes. One or more SLP DAs are used for each scope. The SLP SAs first issue a register message containing all of the services that they provide to the SLP DAs. The SLP DAs will then reply with acknowledgements to the SLP SAs. The advertisements must be refreshed by the SLP SAs periodically before the timer expires. When the user wants to find a desired service, the SLP UA will send a unicast request with the query service to the SLP DA. The SLP DA will reply with a unicast message containing the service's location to the SLP UA.
M.-X. Chen, T.-C. Tzeng / Computer Standards & Interfaces 33 (2011) 271–279
3.1.2. Universal Plug and Play Universal Plug and Play (UPnP) technology was proposed by Microsoft in 1999, and developed by the UPnP Forum. UPnP is a collection of standardized network protocols that enable network devices to automatically discover and control various network devices without complicated setup and human intervention. The UPnP architecture is a distributed, open architecture that offers peer-to-peer networking of network devices and services. UPnP is based on existing Internet application protocols such as HTTP, UDP, IP, and XML, and uses the standard URI address format. Three kinds of components are involved in the UPnP architecture. There are service, device and control points. In UPnP, a service contains some parameters used to maintain the operating status of the service. The devices provide the services. A device works as a server and needs to respond to a request from the control points. The control point is a key component in the UPnP architecture. It works as a device manager entity. The control point is used to retrieve the service information from the devices. The services information contains the service description, operating status, and so on. The control point can also send a command request to control the service and monitor the operating status of a desired service. Service discovery is also provided in the UPnP standard, which is defined in the Simple Service Discovery Protocol (SSDP). When the device is attached to the network, the devices should announce their services by multicasting. The control points can then receive the advertisement, and subsequently use these capabilities. When the control point is attached to the network it also can subscribe to the desired devices and services using SSDP. 3.1.3. Open Service Gateway Initiative Open Service Gateway Initiative (OSGi), established in 1999, is an industry plan for a standard way to define and promote open specifications for the delivery of managed broadband services to networks in homes, cars, and other environments. OSGi involves device manufacturers, software suppliers, gateway operators, and service providers. With the specifications, the service providers and application developers can deploy and manage home network services and devices remotely. For example, service providers can install a security system and be able to change from one monitoring service to another without having to install a new system. Thus, the OSGi platform is a central coordinating point that can manage home network devices or services, spanning multiple heterogeneous communication protocols and technologies. The OSGi framework is written using the Java programming language. The framework is meant to facilitate the deployment of services and applications on a residential gateway. OSGi offers an application programming interface (API), built by Java, allow programmers to design and implement their applications and services. Three kinds of components are involved in the OSGi architecture. They are the framework, bundle, and service. The OSGi framework is a serviceoriented architecture that needs to be running on the Java Virtual Machine (JVM), and is responsible for managing various services. The bundles are the application programs running on the framework. The service is a set of java classes and interfaces implemented in the bundles. These bundles are dynamically loaded, managed and instantiated by the framework. In the OSGi environment, the bundles contain Java classes and other resources that can provide functions to end-users, other devices and can be used by other bundles. These functions and resources are called services. A bundle is implemented as a Java Archive (JAR) file. There are six states during the active life of a bundle. There are the install state, resolve state, start state, active state, stop state and uninstall state. When a bundle is in the start state, its functions and services are registered into the Service Registry and can be exposed to other bundles installed in the OSGi platform. Moreover, the bundle also can import services provided by the other bundles running on the
273
OSGi platform from the Service Registry. The communication mechanism between these bundles is also implemented in the OSGi framework. In fact, the OSGi framework is also implemented as a bundle. Thus, these bundles can use the framework bundle to access other functions. 3.1.4. Session Initiation Protocol The Session Initiation Protocol (SIP) proposed by IETF, is an application layer signaling protocol for creating, modifying, and terminating sessions with one or more devices. The VoIP and 3GPP communities have adopted the Session Initiation Protocol as their choice for signaling protocol. It is designed to be independent of the underlying transport protocols and can be used to establish one or multiple sessions that include multimedia streams, such as audio, video and text information. SIP is also widely used as a signaling protocol to control network appliances in home networks. Four network components are involved in the SIP architecture. There are user agents (UAs), registrars, proxy servers, and redirect servers. The SIP UA is a software entity used to create and manage a SIP session. The SIP UA, which sends the session management message to another SIP UA, is the User Agent Client (UAC). The SIP UA, which responds to SIP requests send by the peer, is the User Agent Server (UAS). The SIP UAs work in point to point mode. The SIP proxy server is a device that acts as the router, which is used to ensure the SIP request send by the UAC is sent to the targeted UAS. It means that the major role of the proxy service is to forward the user request to the targeted UA. The registrar is a server used to admit the REGISTER requests send from the UA, and to store the information retrieved from the REGISTER message into the location service. The redirect server is a user agent server used to direct SIP INVITE message to an alternated UA. When a user wants to create a session with his friend, in the first, he should send the REGISTER messages from his UA to his registrar. Each user agent has a Uniform Resource Identifier (URI). The SIP URI has the form of an e-mail address. The user can put his friend's URI into the INVITE message and send it to the proxy server. The proxy server will forward the INVITE message to the target UA according to the URI. Finally, when his friend accepts the connection request, the response message will be send to the original UA. 3.2. System overview This work emphasizes the application of the OSGi-based platform to combine the component of SLP, UPnP and SIP, in order to achieve services and devices automation discovery. As shown in Fig. 1, our OSGi-based platform was implemented based on three Java based open sources: OW2 Forge Oscar [18], Eclipse ECF Project jSLP [19], and SIP Communicator [20]. Oscar is an open source project for the OSGi framework, which is implemented by the OW2 Consortium. The OW2 Consortium is an open source software community. The aim of the OW2 Consortium is to develop component-based middleware for large scale distributed systems. The OSGi framework and a lot of bundles were implemented in Oscar. In the paper, we implement our system architecture based on the Oscar project. jSLP is a Java based project for SLP. The APIs of jSLP were derived from RFC 2614, and run on J2SE. The functions of the SLP UA, the SA
Fig. 1. Prototype architecture.
274
M.-X. Chen, T.-C. Tzeng / Computer Standards & Interfaces 33 (2011) 271–279
and the DA were provided in jSLP. jSLP also supports peer-to-peer service discovery via multicast messages, and client server discovery procedure with the SLP DA. Since jSLP is implemented by Java, it can run on the OSGi framework to support locate services. SIP communicator is a completely Open Source and Free Software, and is freely available under the terms of the GNU Lesser General Public License. The SIP communicator is a Java based SIP User Agent. It implements a JsPhone application built on top of the Java APIs for Integrated Networks SIP (JAIN-SIP-RI) and Java Media Framework (JMF). Thus, the SIP communicator provides multimedia sessions for the IPv4 and IPv6 networks. As shown in Fig. 2, the system of the OSGi-based gateway with heterogeneous service discovery support can be divided into two parts: the user agent supporting SIP and SLP, and the Gateway supporting SIP, SLP and UPnP. The functions of the SIP UA and the SLP UA will be integrated in the SISUA, which are proposed in [10,11]. The SIP UA, the SLP SA and the DA functions will be integrated into the Gateway. As shown in the block of the SISUA, the SLP UA functions are denoted as “Locator”, and the SIP UA functions are denoted as “Controller”. The blocks in the OSGi block can be classified into four groups. There are the OSGi service, the SLP services, the UPnP services, and the SIP service. The SLP services contain the JSLP service and the SA CP. The JSLP service has all of the SLP functions, such as the SLP UA, the SA, and the DA. The SA CP is used to collect all the services that can be accessed by the Internet and registered into the Service Registry. These services are advertised into the SLP DA. The SIP service is improved in the SISUA, and
the OSGi service denotes all the original OSGi modules. The UPnP services contain the UPnP Driver, the UPnP Utilities, the UPnP TV, the UPnP Webcam, and the UPnP CP. The UPnP Driver works as the Bridge bundle between the UPnP services and the OSGi framework. The UPnP Utilities are the API, and the UPnP CP is the UPnP control point which can be used for discovery to obtain information on the UPnP devices. The UPnP TV is an UPnP virtual device, and is used to simulate a network Television, and the UPnP Webcam is an UPnP device and can be used to control the webcam attached in the Gateway. 3.3. System modules In the section, the detail functions of each module will be decrypted. 3.3.1. OSGi services The OSGi service involves two bundles. There are osgi.jar bundle and osgi-service.jar bundle. The osgi.jar has lots of basic operation API of the OSGi framework, such as BundleActivator (used to start or stop the bundle), BundleContext (used to interact with Service Registry), ServiceReference (used to retrieve the service information), ServiceListener (used to retrieve the bundle information from the Service Registry), ServiceFactory (used to implement the service object), and the ServiceRegistration (Service Registry). The osgi-service.jar provides the service API of the OSGi framework, such as Log, and UPnP, which can be used to implement the UPnP Virtual Device.
Fig. 2. System architecture.
M.-X. Chen, T.-C. Tzeng / Computer Standards & Interfaces 33 (2011) 271–279
3.3.2. JSLP service The JSLP service is implemented by the jslp-osgi.jar bundle. The JSLP service provides all of the SLP functions. The SLP SA is implemented by the Advertiser API, the SLP UA is implemented by the Locator API, and the SLP DA is implemented by the SLPDaemon API. The SLPCore API is used to forward the messages between the SLP UA, the SLP SA, and the SLP DA. 3.3.3. SA CP The SA CP is implemented by SAControlPoint.jar bundle, which works as the SLP SA, and the UPnP Control Point. The SA CP retrieves the Advertiser of JSLP and the ServiceReference of the UPnP Device from the Service Registry, and uses the getProperty method provided by ServiceReference to get the service information of the UPnP devices. The SA CP then advertises these services into the SLP DA. 3.3.4. UPnP Driver The UPnP Driver is implemented using the upnpbasedriver-3.0.2bin.jar bundle and upnpbaseextra-1.0.0-bin.jar bundle. The upnpbasedriver-3.0.2-bin.jar works as the Bridge bundle between the UPnP services and the OSGi framework. The upnpbasedriver-3.0.2-bin.jar has two major functions. There are Exporter and Importer. The Exporter is used to export the services of the UPnP virtual device, which are registered in the Service Registry, to the UPnP environment. Thus, the real UPnP devices can access the services provided by the UPnP virtual device. The importer is used to register the services provided by the real UPnP devices into the Service Registry. The other APIs, such as UPnPException, DriverController, and DevicesInfo were implemented in upnpbaseextra-1.0.0-bin.jar. 3.3.5. UPnP Utilities The domowareutil.jar bundle and upnpgenutil.jar bundle are involved in the UPnP Utilities. The event APIs, such as UPnPSubscriber
275
(used to subscribe the state information of UPnP devices), UPnPEventNotifier (used to send event), Lookup (used to search the UPnP device), and EventSource (used to generate the UPnP event), are implemented in the domowareutil.jar bundle. The abstract interfaces of UPnP API are implemented in the upnpgenutil.jar bundle. 3.3.6. UPnP CP The UPnP CP is implemented by controlpoint-2.1.0-bin.jar bundle, works as an UPnP Control Point, and can be used to detect the UPnP devices, to retrieve the service information of the UPnP devices, to control the UPnP devices, and to subscribe the state information of the UPnP devices. 3.3.7. UPnP TV and UPnP Webcam The UPnP TV is implemented by simpleupnptv.jar bundle, and UPnP Webcam is implemented by upnpwebcam.jar bundle. Both these two bundles are UPnP virtual devices, and extended from the osgi-service.jar, domowareutil.jar and upnpgenutil.jar. 3.3.8. SISUA The SISUA is implemented by sisua.jar bundle, which works as the SIP UA, and used to forward the messages between Controller of the SISUA and the UPnP devices. 3.4. System operations The operations of these services are shown in Fig. 2. In the first, when the OSGi service is starting, the JSLP, the UPnP TV, and the UPnP Webcam will register their services into the Service Registry, as the steps 1, 2, and 3. In step 4, the SA CP will then retrieve these services from the Service Registry. In step 5, SA CP advertises these services to the SLP DA, which is provided by the JSLP. The user can send the service location request from the Locator of the SISUA to the SLP DA,
Fig. 3. The SLP procedure.
276
M.-X. Chen, T.-C. Tzeng / Computer Standards & Interfaces 33 (2011) 271–279
Fig. 4. SISUA GUI.
and gets the service URL of the UPnP TV and the UPnP Webcam, as the steps 6 and 7. In step 8, the user can select one of these services, and send the control message from the Controller of the SISUA to the SISUA in the Gateway. In step 7, the SISUA of OSGi will retrieve the service information of the UPnP TV and the UPnP Webcam from the Service Registry. Once the SISUA receives the control messages from
the Controller, it will forward the control messages to the UPnP TV (step 10) and the UPnP Webcam (step 11), and forwards the response messages from these services to the Controller in step 12. The detailed SLP procedure is shown in Fig. 3. The Advertiser for the SA CP will first retrieve the services from the Service Registry and register these services to the SLPDaemon through the A-SLPCore.
Fig. 5. SISUA GUI example.
M.-X. Chen, T.-C. Tzeng / Computer Standards & Interfaces 33 (2011) 271–279
277
Fig. 6. Control menu of UPnP device.
Then, the A-SLPCore will forward the acknowledgement replied by SLPDaemon to the Advertiser. Thus, the SLP UA can discover this service information from the SLP DA. In order to control the UPnP devices from the Controller on the SISUA, we add a new SIP extension header, referred as Message Header, to carry the control message. Thus, when the user wants to control the UPnP device from the SISUA, the Controller will put the control command, the URI of the SISUA on the Gateway, and the service information of the UPnP device into the Message Header in the SIP request message and send the message to the SISUA on the Gateway. The SISUA on the Gateway will then retrieve the control
command and service information of the UPnP device from the Message Header in the SIP request message, and convert the control command upon the UPnP format, and send it to the targeted device. Once the SISUA on the Gateway receives the response message from the UPnP device, the SISUA will convert the response message into the SIP response message. The URI of the SIP UA is also placed in the SIP response message. Finally, the SISUA on the Gateway sends the response message to the SISUA Controller. 4. System implementation 4.1. Prototype architecture
Fig. 7. Experimental environment.
In the paper, we integrate the SIP communicator into the OSGibased platform. As shown in Fig. 4.a, we also integrate SLP UA into the SISUA proposed in [10], which was derived from the SIP communicator. Fig. 4.b is the control interface of the UPnP devices. When the SISUA finds the UPnP devices, the control button will be shown in the panel. The user can press the button to invoke the control menu of the UPnP device. As shown in Fig. 5.a, the SLP panel is used to show the SLP UA. We can enter the desired service type (such as SIP or UPnP) in the search type field. Then, we can receive the desired service information from the SLP SA by multicast messages or from the SLP DA by unicast message. We also can enter the LDAP Search Filter String in the Predicate to discover the abstract services. As shown in Fig. 5.b, the UPnP panel is used to show the subscribed UPnP device. We can enter the icon of UPnP device to open the control menu of UPnP device. For example, Fig. 6.a is the control menu for the UPnP TV, and Fig. 6.b is the control menu for the UPnP Webcam. The power field of
Fig. 8. UPnP devices registry.
278
M.-X. Chen, T.-C. Tzeng / Computer Standards & Interfaces 33 (2011) 271–279
Fig. 9. The execution time of UPnP devices registry.
Fig. 11. The turnaround time of service discovery.
the control menu for the UPnP TV is used to start or stop the UPnP TV service, and the channel field is used to change the TV channel. The power field of the control menu for the UPnP Webcam is used to start or stop the UPnP Webcam service. As shown in Fig. 6.c, when we press the show icon, the captured images will be transferred from the UPnP Webcam. 4.2. Performance evaluations To study the performance of our OSGi-based platform, we have conducted experiments with our prototype implementations. As shown in Fig. 7, we built an experimental environment with three devices. The OSGi-based platform is hosted on PC1 with Intel Duo T2250 1.73 GHz and 1.0GB RAM, and the SISUA is hosted on PC2 with Intel Duo E6300 1.86 GHz and 1.0 GB RAM. The UPnP virtual devices, the UPnP TV, and UPnP Webcam are attached on the OSGi-based platform. The PC3 with Intel P4/3.01 GHz and 1.0 GB RAM, is used to generate background traffics between PC1 and PC3. The background traffics are the number of TCP connection requests per second. In the experiment, we want to measure the execution time of each execution between the PC1 and the PC2. The execution details are described below. In the first kind of executions as shown in Fig. 8, the UPnP devices will register their services into the Service Registry, and the SA CP will retrieve these services, and then advertise them into the SLP DA. The total execution times are shown in Fig. 9. The second scenario as shown in Fig. 10, is to measure the turnaround time between the SISUA Locator and the SLP DA on the OSGi platform. The results of second scenario are shown in Fig. 11. The third execution as shown in Fig. 12 is a sequence of control command from the Controller to the UPnP TV or the UPnP Webcam. Upon receiving a control command from the Controller, the OSGi platform has to forward the
control command to the UPnP device, and then forwards the response message to the Controller. The turnaround times of each execution between the Controller and the UPnP device are shown in Fig. 13. As shown in Fig. 9, the execution time for service registry is very stable, and is not affected by the amount of background traffic. From Fig. 11, we can know that the turnaround time for service discovery will increase slightly when the amount of background traffic increases. In contrast, the turnaround time for service control is increased when the amount of background traffic increases. That is because the OSGi framework should process the messages passing between the Controller and the UPnP devices. Although the turnaround time of service control will increase when the amount of background traffic increases. In the realistic home network environment, the amount of TCP requests between the residential gateway and home appliances will be bound. However, the performance of the residential gateway will decrease when the amount of TCP requests from the external network increases. The firewall is the front line defense mechanism against intruders, and block traffic from the outside [21,22]. The firewall can use the packet filter to filter packet, and has the ability to filter or block traffic to and from a network. We can place the firewall between the external network link and the residential gateway, and the amount of TCP requests from the external network will be controlled by the firewall. Thus, with the firewall, our proposed residential gateway can provide better performance. 5. Conclusions and future works Ubiquitous computing in home networks has gone more increased attention over the past few years. We proposed an OSGi-based residential gateway to provide heterogeneous services or automatic
Fig. 10. Service discovery.
M.-X. Chen, T.-C. Tzeng / Computer Standards & Interfaces 33 (2011) 271–279
279
Fig. 12. Service control.
Fig. 13. The turnaround time of service control.
device discovery, registry, and management. The SLP SA, the DA, the SIP UA, and the UPnP control point are integrated into the OSGi-based residential gateway. We also integrated the SLP UA, the SIP UA and UPnP control interface into the SISUA. Our implementation provides easy heterogeneous services and device operation with other networks. From the evaluation results, the performance of our Gateway will decrease when the number of TCP requests increases. We think that this problem is not very serious in a home network environment. Traffics from external networks can be easily controlled by the firewall. In the future, we will extend the OSGi platform capabilities to support an intelligent digital home network security system.
References [1] JXTA(TM) Community Projects, https://jxta.dev.java.net. [2] UPnP Forum, http://www.upnp.org. [3] J. Veizades, E. Guttman, C. Perkins and S. Kaplan, “Service Location Protocol”, RFC 2165, IETF July 1997. [4] E. Guttman, C. Perkins, J. Veizades, and M. Day, “Service Location Protocol, Version 2”, RFC 2608, IETF June 1999. [5] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley and E. Schooler, “SIP: Sesson Initiation Protocol”, RFC 3261, IETF June 2002. [6] Open Service Gateway Initiative, http://www.osgi.org/. [7] H. Schulzrinne, Wu. Xiaotao, S. Sidiroglou, S. Berger, Ubiquitous computing in home networks, IEEE Communications Magazine 41 (11) (Nov. 2003) 128–135. [8] R. Shacham, S. Schulzrinne, S. Thakolsri, W. Kellerer, The virtual device: expanding wireless communication services through service discovery and session mobility, IEEE International Conference on Wireless and Mobile Computing, Networking and Communications 4 (Aug. 2005) 73–81. [9] Min-Xiou Chen, Chen-Jui Peng, Ren-Hung Hwang, SSIP: split a SIP session over multiple devices, Computer Standards and Interfaces 29 (5) (July 2007) 531–545. [10] Min-Xiou Chen, and Fu-Ju Wang, “Session Mobility of SIP over Multiple Devices”, Tridentcom 2008, Innsbruck, Austria, March 18–20, 2008. [11] P. Dobrev, D. Famolari, C. Kurzke, B.A. Miller, Device and service discovery in home networks with OSGi, IEEE Communications Magazine 40 (8) (Aug. 2002) 86–92. [12] D. Bushmitch, Wanrong Lin, A. Bieszczad, A. Kaplan, V. Papageorgiou, A. Pakstas, A SIP-based device communication service for OSGi framework, IEEE Consumer Communications and Networking Conference, Jan. 2004, pp. 453–458.
[13] C. Guiran, Z. Chuan, Matthew Y. Ma, Z. Weiguo, Z. Jingbo, Implementing a SIPbased Device Communication Middleware for OSGi Framework with Extension to Wireless Networks, International Multi-Symposiums on Computer and Computational Sciences, Vol. 2, April 2006, p. 603-310. [14] H. Schmidt, T. Guenkova-Luy, F.J. Hauck, Service location using the Session Initiation Protocol (SIP), International Conference on Networking and Services (2006) 60-60. [15] Yao-Chung Chang, Jiann-Liang Chen, Han-Chieh Chao, Sy-Yen Kuo, OSA-based service platform for all-IPv6 network environments, IEEE Journal on Selected Areas in Communications 23 (11) (November 2005) 2172–2181. [16] Wu. Chao-Lin, Chun-Feng Liao, Fu. Li-Chen, Service-oriented smart-home architecture based on OSGi and mobile-agent technology, IEEE Transactions on Systems, Man, and Cybernetics, Part C: Applications and Reviews 37 (2) (March 2007) 193–205. [17] Y. Ai, Y. Sun, W. Huang, X. Qiao, OSGi Based Integrated Service Platform for Automotive Telematics, IEEE International Conference on Vehicular Electronics and Safety, December 2007, pp. 1–6. [18] OW2 Forge: Project Info-Oscar-OSGi Framework, http://forge.objectweb.org/ projects/oscar/. [19] jSLP, http://jslp.sourceforge.net/. [20] SIP Communicator, http://sip-communicator.org/. [21] A. Householder, K. Houle, C. Dougherty, Computer attack trends challenge Internet security, Computer 35 (4) (Apr 2002) 5–7. [22] Olalekan Adeyinka, Internet attack methods and internet security technology, Second Asia International Conference on Modelling & Simulation, May 2008.
Min-Xiou Chen is an Assistant Professor of the Department of Computer Science and Information Engineering, National Dong Hwa University, Hualien, Taiwan, ROC from 2008. Prof. Chen received the B.S. degree in Computer and Information Science from Tung Hai University, Tai-Chung, Taiwan, ROC in 1996, and M.S. and Ph.D. degrees in Computer Science and Information Engineering from National Chung Cheng University, Chia-Yi, Taiwan, ROC in 1998 and 2005, respectively. In August 2005, Prof. Chen joined the faculty of the Department of Computer Science and Information Engineering, Chung Hua University, as an Assistant Professor. Since August 2008, Prof. Chen joined the Department of Computer Science and Information Engineering, National Dong Hwa University. His research interests include wireless communication, VANET, home network, sensor network and resource management in next-generation personal communication system.
Tze-Chin Tzeng received the B.S. and M.S. degrees in Computer Science and Information Engineering from the Chung-Hua University, HsinChu, Taiwan. He works as an engineer at the Network Benchmarking Laboratory, Nation Chiao Tung University, HsinChu, Taiwan. He is currently working on voice/video over IP, NAT traversal, network content security, and real flow application.
Contents lists available at ScienceDirect
Computer Standards & Interfaces j o u r n a l h o m e p a g e : w w w. e l s ev i e r. c o m / l o c a t e / c s i
Integrating service discovery technologies in OSGi platform☆ Min-Xiou Chen a,⁎, Tze-Chin Tzeng b a b
Department of Computer Science and Information Engineering, National Dong Hwa University, 1, Sec. 2, DaHsueh Rd., Shou-Feng, Hualien, Taiwan, ROC Department of Computer Science and Information Engineering, ChungHua University, 707, Sec.2, WuFu Rd., Hsinchu, Taiwan, ROC
a r t i c l e
i n f o
Article history: Received 1 February 2009 Received in revised form 25 December 2009 Accepted 25 May 2010 Available online 15 June 2010 Keywords: Home network Open Service Gateway Initiative Service Location Protocol Session Initiation Protocol Universal Plug and Play
a b s t r a c t This paper describes the service discovery and interaction for home network devices using heterogeneous standards and protocols. OSGi was proposed to allow several kinds of services coming from different providers to be loaded and run on a gateway. We present a residential gateway based on the OSGi architecture for a smart home network. We combine the SLP SA/DA, the UPnP control point and the SIP UA into the gateway to achieve automated device discovery, registry, and management. Application examples are introduced and the implementation results show that our gateway can provide automatic heterogeneous service or device discovery, registry, and management. © 2010 Elsevier B.V. All rights reserved.
1. Introduction In the past decade, communication technology has undergone a tremendous change. Due to the fast and prosperous advancement of online communication technologies, network service can greatly facilitate human daily life. With the rapid expansion of the Internet and the availability of communication technologies, networked home appliances are proliferating at an accelerated pace. For example, more commonplace home appliances are being interconnected with the Internet. Various network services and multimedia services are available throughout the network. Through the network, users can remote access and control over home electrical appliances from office. With the number of networked devices or services within the home, an efficient interconnection protocol and management platform has become crucial research work. For a service consumer, it is difficult to have a complete overview of these services and their availability. These devices produced by different manufacturers have different communication protocols. The dynamics of network devices and services make this process even more complex. Finding the available network service and devices becomes an important issue for constructing a home network. The service discovery mechanism was proposed to support the user in finding available network services or devices. Therefore, the service consumer can find or access network devices or services through the network that are capable of interacting with
☆ This work was supported by the National Science Council of Taiwan, R.O.C. under Grant NSC95-2221-E-216-039, NSC96-2221-E-216-010, and NSC97-221-E-259-036. ⁎ Corresponding author. E-mail addresses: [email protected] (M.-X. Chen), [email protected] (T.-C. Tzeng). 0920-5489/$ – see front matter © 2010 Elsevier B.V. All rights reserved. doi:10.1016/j.csi.2010.05.004
each other using the service discovery mechanism. Numerous protocols, middleware, and standards, such as JXTA [1], UPnP [2], SLP [3,4], and SIP [5], have proposed for interconnection or discovery with these home networked devices. A lot of researches implement a residential gateway based on the OSGi plan to interconnect or discover heterogeneous network devices or services. OSGi (Open Service Gateway Initiative) [6] defines open specifications and standards for the delivery of managed services to networked environments. It is an industry plan for a standard way to connect network devices such as home appliances or network services. The OSGi framework allows several kinds of services coming from different providers to be loaded and run on a service gateway. The OSGi platform can serve as the central coordinating point for managing the home network, spanning multiple heterogeneous communication technologies. Although, the OSGi platform can serve as the central coordinating point for spanning multiple heterogeneous communication technologies, the devices still cannot discover the UPnP services and devices using SLP or JXTA. It is because that these service discovery standards and protocols are mostly proprietary and do not operate easily with other networks. This paper proposes and implements a way to bind several home network protocols, making the devices or services of one network discoverable to others. We present a residential gateway based on the OSGi architecture for a smart home network. To achieve automated heterogeneous devices discovery, registry and management, the SLP (Service Location Protocol) SA/DA component, the UPnP (Universal Plug and Play) control point and the SIP (Session Initiation Protocol) UA, will be integrated into the OSGi platform. We also integrate the SLP UA, UPnP control interface into the SIP UA. Based on our proposed architecture, the user can easily discover and access the UPnP devices and service using the SLP UA and SIP UA.
272
M.-X. Chen, T.-C. Tzeng / Computer Standards & Interfaces 33 (2011) 271–279
The remainder of this paper is organized as follows. The related literatures on session discovery are discussed in Section 2. Section 3 proposes the OSGi-based control architecture, as well as how the SLP SA/DA, the UPnP control point and the SIP UA can be combined into the gateway. The implementation architecture and the implementation results from our architecture are described in Section 4. Finally, we draw our conclusions and some future works in Section 5.
interaction model with the OSGi platforms to provide the ability to interconnect networks with different technologies. In [17], Ai et al. improve the OSGi platform to support automotive telematics. However, the service discovery mechanism was not considered in their architecture.
3. System architecture 2. Related works 3.1. Related protocols The aim of ubiquitous computing is to integrate computer devices and network services into daily human life. The user can access any telecom or datacom service as voice, video or data, anywhere at any time with any devices. Therefore, this is a desirable service if a user can change the communication device adaptively, according to his surrounding environment, during a communication session. In [7], Schulzrinne et al. proposed an intelligence system, that provides a ubiquitous computing environment in the home network. To provide ubiquitous computing a lot of techniques and services should be integrated into the intelligence system. The location sensing service is the key component used to locate the user's position. Based on the correct position information, the intelligence system can provide available services or devices to the user. The Bluetooth technique, GPS, and sensor network can be used in the location sensing services. The resource discovery and control servers provide the user with available service or devices for controlling these services and devices. The SLP and SIP were introduced to provide service discovery and control. The access control system allows the user to remote control home appliances. Based on the architecture proposed in [7], Shacham et al. proposed the detail implementation in [8]. In [8], the SLP was used to search for service, with SIP used to control the network devices. To provide session mobility over multiple devices, the “Virtual Device” concept or a Multi-Device System (MDS) was introduced. Two different modes were involved in their system. In the Mobile Node Control (MNC) mode, the user agent transfers and retrieves the session using a Third Party Call Control (3PCC) mechanism. Session Handoff (SH) mode uses REFER method, which is a SIP extension method defined in RFC 3515, to establish a SIP session with each device. To efficiently manage the session over multiple devices, the Multi-Device System Manager (MDSM) was introduced. We also proposed a mechanism, referred to as “Split a SIP session over multiple devices (SSIP)” [9], to provide split session service. Some improvements were involved in our mechanism to obtain the ability to split a session. The extension header “Mobility” was introduced to improve the REFER method and make it transparent to the remote party. The “Association” record was used to terminate all split sessions separately when a session was split over multiple devices. Moreover, in order to facilitate transferring, splitting and retrieving a session over multiple devices, we proposed a complete mechanism, referred to as “Session Integration Service” [10]. In order to provide facility session mobility, three new agents, session manager, session user, and free node were introduced in our mechanism. The session manager transformation (SMT) procedure and the session manager acquirement (SMA) procedure were introduced to provide much more flexibility in session mobility. To integrate the service discovery service in the home network, Dobrev et al. introduced the OSGi platform to solve the problem in [11]. Based on the Bridge bundle, the UPnP services and Jini services were working as the services in the OSGi platform. Thus, the OSGi services and the UPnP devices can be interconnected. In [12,13], the authors proposed a solution that uses the SIP and the Bridge bundle of the OSGi platform to interconnect and access heterogeneous network devices or services. [14] proposed a solution to provide service discovery by SIP. In [15], the OSGi platform was improved to support the ALL-IPv6 environments. In [16], Wu et al. proposed a P2P
3.1.1. Service Location Protocol The Service Location Protocol (SLP), defined by IETF, is an Internet standard network protocol that supports the user in finding the existence, location and configuration of available network services. This protocol enables service registration and simplifies any subsequent search for services. SLP is used by devices to announce services or discover services on an unmanaged network. Each service can be located using the Uniform Resources Locators (URLs). The URL can have an IP address or the domain name, and the service type. The service types can be classified into a particular service type or abstract service type. The well known network services, such as http, ftp, and so on, are belonged to a particular service type. The abstract service type is associated with a variety of different service agents, such as a printer, webcam and so on. To efficiently manage and discover services three network components are involved in the SLP architecture. They are Service Agents (SAs), Directory Agents (DAs) and User Agents (UAs). The SLP SA is a device that provides one or more services in a network. The SLP SA can advertise services to the SLP DA or provide service information to the SLP UA when the desired service matched. The SLP DA is a process that manages the services registered from the SLP SAs, or applications stored in DA's local database. The SLP DA can provide service information when the SLP UA sends its discovery request. The SLP UA is a software entity used to search for network services. Without any network service or network host names, the users can find the available services using only a description of the desired service. The SLP UA sends a request with the description to the SLP SA or the SLP DA, and the SLP SA or the SLP DA will then return the response with the URL for the desired service. SLP can support the network scale from small, unmanaged networks to large enterprise networks. All the network devices and services can be grouped into several scopes. Each device or service should be in one or more scopes. In SLP, the scope is a set of network devices or services. A scope can be described as a simple string and denoted as the domain name in a campus network or the department name in an enterprise network. The SLP UA can only search the network devices or services from its scope. SLP allows the administrators of a scope to organize users, network devices and servers into administrative groups. In SLP, the SLP UA can directly send search requests to the SLP SA. In this case, the SLP UA sends a request by multicasting. When the SLP SA receives a request that it can service, the SLP SA will reply with a unicast message containing the service's location to the SLP UA. This kind of approach is suitable for small, unmanaged networks. In larger networks, as the number of SLP SAs grows, it becomes necessary to partition these devices into several scopes. One or more SLP DAs are used for each scope. The SLP SAs first issue a register message containing all of the services that they provide to the SLP DAs. The SLP DAs will then reply with acknowledgements to the SLP SAs. The advertisements must be refreshed by the SLP SAs periodically before the timer expires. When the user wants to find a desired service, the SLP UA will send a unicast request with the query service to the SLP DA. The SLP DA will reply with a unicast message containing the service's location to the SLP UA.
M.-X. Chen, T.-C. Tzeng / Computer Standards & Interfaces 33 (2011) 271–279
3.1.2. Universal Plug and Play Universal Plug and Play (UPnP) technology was proposed by Microsoft in 1999, and developed by the UPnP Forum. UPnP is a collection of standardized network protocols that enable network devices to automatically discover and control various network devices without complicated setup and human intervention. The UPnP architecture is a distributed, open architecture that offers peer-to-peer networking of network devices and services. UPnP is based on existing Internet application protocols such as HTTP, UDP, IP, and XML, and uses the standard URI address format. Three kinds of components are involved in the UPnP architecture. There are service, device and control points. In UPnP, a service contains some parameters used to maintain the operating status of the service. The devices provide the services. A device works as a server and needs to respond to a request from the control points. The control point is a key component in the UPnP architecture. It works as a device manager entity. The control point is used to retrieve the service information from the devices. The services information contains the service description, operating status, and so on. The control point can also send a command request to control the service and monitor the operating status of a desired service. Service discovery is also provided in the UPnP standard, which is defined in the Simple Service Discovery Protocol (SSDP). When the device is attached to the network, the devices should announce their services by multicasting. The control points can then receive the advertisement, and subsequently use these capabilities. When the control point is attached to the network it also can subscribe to the desired devices and services using SSDP. 3.1.3. Open Service Gateway Initiative Open Service Gateway Initiative (OSGi), established in 1999, is an industry plan for a standard way to define and promote open specifications for the delivery of managed broadband services to networks in homes, cars, and other environments. OSGi involves device manufacturers, software suppliers, gateway operators, and service providers. With the specifications, the service providers and application developers can deploy and manage home network services and devices remotely. For example, service providers can install a security system and be able to change from one monitoring service to another without having to install a new system. Thus, the OSGi platform is a central coordinating point that can manage home network devices or services, spanning multiple heterogeneous communication protocols and technologies. The OSGi framework is written using the Java programming language. The framework is meant to facilitate the deployment of services and applications on a residential gateway. OSGi offers an application programming interface (API), built by Java, allow programmers to design and implement their applications and services. Three kinds of components are involved in the OSGi architecture. They are the framework, bundle, and service. The OSGi framework is a serviceoriented architecture that needs to be running on the Java Virtual Machine (JVM), and is responsible for managing various services. The bundles are the application programs running on the framework. The service is a set of java classes and interfaces implemented in the bundles. These bundles are dynamically loaded, managed and instantiated by the framework. In the OSGi environment, the bundles contain Java classes and other resources that can provide functions to end-users, other devices and can be used by other bundles. These functions and resources are called services. A bundle is implemented as a Java Archive (JAR) file. There are six states during the active life of a bundle. There are the install state, resolve state, start state, active state, stop state and uninstall state. When a bundle is in the start state, its functions and services are registered into the Service Registry and can be exposed to other bundles installed in the OSGi platform. Moreover, the bundle also can import services provided by the other bundles running on the
273
OSGi platform from the Service Registry. The communication mechanism between these bundles is also implemented in the OSGi framework. In fact, the OSGi framework is also implemented as a bundle. Thus, these bundles can use the framework bundle to access other functions. 3.1.4. Session Initiation Protocol The Session Initiation Protocol (SIP) proposed by IETF, is an application layer signaling protocol for creating, modifying, and terminating sessions with one or more devices. The VoIP and 3GPP communities have adopted the Session Initiation Protocol as their choice for signaling protocol. It is designed to be independent of the underlying transport protocols and can be used to establish one or multiple sessions that include multimedia streams, such as audio, video and text information. SIP is also widely used as a signaling protocol to control network appliances in home networks. Four network components are involved in the SIP architecture. There are user agents (UAs), registrars, proxy servers, and redirect servers. The SIP UA is a software entity used to create and manage a SIP session. The SIP UA, which sends the session management message to another SIP UA, is the User Agent Client (UAC). The SIP UA, which responds to SIP requests send by the peer, is the User Agent Server (UAS). The SIP UAs work in point to point mode. The SIP proxy server is a device that acts as the router, which is used to ensure the SIP request send by the UAC is sent to the targeted UAS. It means that the major role of the proxy service is to forward the user request to the targeted UA. The registrar is a server used to admit the REGISTER requests send from the UA, and to store the information retrieved from the REGISTER message into the location service. The redirect server is a user agent server used to direct SIP INVITE message to an alternated UA. When a user wants to create a session with his friend, in the first, he should send the REGISTER messages from his UA to his registrar. Each user agent has a Uniform Resource Identifier (URI). The SIP URI has the form of an e-mail address. The user can put his friend's URI into the INVITE message and send it to the proxy server. The proxy server will forward the INVITE message to the target UA according to the URI. Finally, when his friend accepts the connection request, the response message will be send to the original UA. 3.2. System overview This work emphasizes the application of the OSGi-based platform to combine the component of SLP, UPnP and SIP, in order to achieve services and devices automation discovery. As shown in Fig. 1, our OSGi-based platform was implemented based on three Java based open sources: OW2 Forge Oscar [18], Eclipse ECF Project jSLP [19], and SIP Communicator [20]. Oscar is an open source project for the OSGi framework, which is implemented by the OW2 Consortium. The OW2 Consortium is an open source software community. The aim of the OW2 Consortium is to develop component-based middleware for large scale distributed systems. The OSGi framework and a lot of bundles were implemented in Oscar. In the paper, we implement our system architecture based on the Oscar project. jSLP is a Java based project for SLP. The APIs of jSLP were derived from RFC 2614, and run on J2SE. The functions of the SLP UA, the SA
Fig. 1. Prototype architecture.
274
M.-X. Chen, T.-C. Tzeng / Computer Standards & Interfaces 33 (2011) 271–279
and the DA were provided in jSLP. jSLP also supports peer-to-peer service discovery via multicast messages, and client server discovery procedure with the SLP DA. Since jSLP is implemented by Java, it can run on the OSGi framework to support locate services. SIP communicator is a completely Open Source and Free Software, and is freely available under the terms of the GNU Lesser General Public License. The SIP communicator is a Java based SIP User Agent. It implements a JsPhone application built on top of the Java APIs for Integrated Networks SIP (JAIN-SIP-RI) and Java Media Framework (JMF). Thus, the SIP communicator provides multimedia sessions for the IPv4 and IPv6 networks. As shown in Fig. 2, the system of the OSGi-based gateway with heterogeneous service discovery support can be divided into two parts: the user agent supporting SIP and SLP, and the Gateway supporting SIP, SLP and UPnP. The functions of the SIP UA and the SLP UA will be integrated in the SISUA, which are proposed in [10,11]. The SIP UA, the SLP SA and the DA functions will be integrated into the Gateway. As shown in the block of the SISUA, the SLP UA functions are denoted as “Locator”, and the SIP UA functions are denoted as “Controller”. The blocks in the OSGi block can be classified into four groups. There are the OSGi service, the SLP services, the UPnP services, and the SIP service. The SLP services contain the JSLP service and the SA CP. The JSLP service has all of the SLP functions, such as the SLP UA, the SA, and the DA. The SA CP is used to collect all the services that can be accessed by the Internet and registered into the Service Registry. These services are advertised into the SLP DA. The SIP service is improved in the SISUA, and
the OSGi service denotes all the original OSGi modules. The UPnP services contain the UPnP Driver, the UPnP Utilities, the UPnP TV, the UPnP Webcam, and the UPnP CP. The UPnP Driver works as the Bridge bundle between the UPnP services and the OSGi framework. The UPnP Utilities are the API, and the UPnP CP is the UPnP control point which can be used for discovery to obtain information on the UPnP devices. The UPnP TV is an UPnP virtual device, and is used to simulate a network Television, and the UPnP Webcam is an UPnP device and can be used to control the webcam attached in the Gateway. 3.3. System modules In the section, the detail functions of each module will be decrypted. 3.3.1. OSGi services The OSGi service involves two bundles. There are osgi.jar bundle and osgi-service.jar bundle. The osgi.jar has lots of basic operation API of the OSGi framework, such as BundleActivator (used to start or stop the bundle), BundleContext (used to interact with Service Registry), ServiceReference (used to retrieve the service information), ServiceListener (used to retrieve the bundle information from the Service Registry), ServiceFactory (used to implement the service object), and the ServiceRegistration (Service Registry). The osgi-service.jar provides the service API of the OSGi framework, such as Log, and UPnP, which can be used to implement the UPnP Virtual Device.
Fig. 2. System architecture.
M.-X. Chen, T.-C. Tzeng / Computer Standards & Interfaces 33 (2011) 271–279
3.3.2. JSLP service The JSLP service is implemented by the jslp-osgi.jar bundle. The JSLP service provides all of the SLP functions. The SLP SA is implemented by the Advertiser API, the SLP UA is implemented by the Locator API, and the SLP DA is implemented by the SLPDaemon API. The SLPCore API is used to forward the messages between the SLP UA, the SLP SA, and the SLP DA. 3.3.3. SA CP The SA CP is implemented by SAControlPoint.jar bundle, which works as the SLP SA, and the UPnP Control Point. The SA CP retrieves the Advertiser of JSLP and the ServiceReference of the UPnP Device from the Service Registry, and uses the getProperty method provided by ServiceReference to get the service information of the UPnP devices. The SA CP then advertises these services into the SLP DA. 3.3.4. UPnP Driver The UPnP Driver is implemented using the upnpbasedriver-3.0.2bin.jar bundle and upnpbaseextra-1.0.0-bin.jar bundle. The upnpbasedriver-3.0.2-bin.jar works as the Bridge bundle between the UPnP services and the OSGi framework. The upnpbasedriver-3.0.2-bin.jar has two major functions. There are Exporter and Importer. The Exporter is used to export the services of the UPnP virtual device, which are registered in the Service Registry, to the UPnP environment. Thus, the real UPnP devices can access the services provided by the UPnP virtual device. The importer is used to register the services provided by the real UPnP devices into the Service Registry. The other APIs, such as UPnPException, DriverController, and DevicesInfo were implemented in upnpbaseextra-1.0.0-bin.jar. 3.3.5. UPnP Utilities The domowareutil.jar bundle and upnpgenutil.jar bundle are involved in the UPnP Utilities. The event APIs, such as UPnPSubscriber
275
(used to subscribe the state information of UPnP devices), UPnPEventNotifier (used to send event), Lookup (used to search the UPnP device), and EventSource (used to generate the UPnP event), are implemented in the domowareutil.jar bundle. The abstract interfaces of UPnP API are implemented in the upnpgenutil.jar bundle. 3.3.6. UPnP CP The UPnP CP is implemented by controlpoint-2.1.0-bin.jar bundle, works as an UPnP Control Point, and can be used to detect the UPnP devices, to retrieve the service information of the UPnP devices, to control the UPnP devices, and to subscribe the state information of the UPnP devices. 3.3.7. UPnP TV and UPnP Webcam The UPnP TV is implemented by simpleupnptv.jar bundle, and UPnP Webcam is implemented by upnpwebcam.jar bundle. Both these two bundles are UPnP virtual devices, and extended from the osgi-service.jar, domowareutil.jar and upnpgenutil.jar. 3.3.8. SISUA The SISUA is implemented by sisua.jar bundle, which works as the SIP UA, and used to forward the messages between Controller of the SISUA and the UPnP devices. 3.4. System operations The operations of these services are shown in Fig. 2. In the first, when the OSGi service is starting, the JSLP, the UPnP TV, and the UPnP Webcam will register their services into the Service Registry, as the steps 1, 2, and 3. In step 4, the SA CP will then retrieve these services from the Service Registry. In step 5, SA CP advertises these services to the SLP DA, which is provided by the JSLP. The user can send the service location request from the Locator of the SISUA to the SLP DA,
Fig. 3. The SLP procedure.
276
M.-X. Chen, T.-C. Tzeng / Computer Standards & Interfaces 33 (2011) 271–279
Fig. 4. SISUA GUI.
and gets the service URL of the UPnP TV and the UPnP Webcam, as the steps 6 and 7. In step 8, the user can select one of these services, and send the control message from the Controller of the SISUA to the SISUA in the Gateway. In step 7, the SISUA of OSGi will retrieve the service information of the UPnP TV and the UPnP Webcam from the Service Registry. Once the SISUA receives the control messages from
the Controller, it will forward the control messages to the UPnP TV (step 10) and the UPnP Webcam (step 11), and forwards the response messages from these services to the Controller in step 12. The detailed SLP procedure is shown in Fig. 3. The Advertiser for the SA CP will first retrieve the services from the Service Registry and register these services to the SLPDaemon through the A-SLPCore.
Fig. 5. SISUA GUI example.
M.-X. Chen, T.-C. Tzeng / Computer Standards & Interfaces 33 (2011) 271–279
277
Fig. 6. Control menu of UPnP device.
Then, the A-SLPCore will forward the acknowledgement replied by SLPDaemon to the Advertiser. Thus, the SLP UA can discover this service information from the SLP DA. In order to control the UPnP devices from the Controller on the SISUA, we add a new SIP extension header, referred as Message Header, to carry the control message. Thus, when the user wants to control the UPnP device from the SISUA, the Controller will put the control command, the URI of the SISUA on the Gateway, and the service information of the UPnP device into the Message Header in the SIP request message and send the message to the SISUA on the Gateway. The SISUA on the Gateway will then retrieve the control
command and service information of the UPnP device from the Message Header in the SIP request message, and convert the control command upon the UPnP format, and send it to the targeted device. Once the SISUA on the Gateway receives the response message from the UPnP device, the SISUA will convert the response message into the SIP response message. The URI of the SIP UA is also placed in the SIP response message. Finally, the SISUA on the Gateway sends the response message to the SISUA Controller. 4. System implementation 4.1. Prototype architecture
Fig. 7. Experimental environment.
In the paper, we integrate the SIP communicator into the OSGibased platform. As shown in Fig. 4.a, we also integrate SLP UA into the SISUA proposed in [10], which was derived from the SIP communicator. Fig. 4.b is the control interface of the UPnP devices. When the SISUA finds the UPnP devices, the control button will be shown in the panel. The user can press the button to invoke the control menu of the UPnP device. As shown in Fig. 5.a, the SLP panel is used to show the SLP UA. We can enter the desired service type (such as SIP or UPnP) in the search type field. Then, we can receive the desired service information from the SLP SA by multicast messages or from the SLP DA by unicast message. We also can enter the LDAP Search Filter String in the Predicate to discover the abstract services. As shown in Fig. 5.b, the UPnP panel is used to show the subscribed UPnP device. We can enter the icon of UPnP device to open the control menu of UPnP device. For example, Fig. 6.a is the control menu for the UPnP TV, and Fig. 6.b is the control menu for the UPnP Webcam. The power field of
Fig. 8. UPnP devices registry.
278
M.-X. Chen, T.-C. Tzeng / Computer Standards & Interfaces 33 (2011) 271–279
Fig. 9. The execution time of UPnP devices registry.
Fig. 11. The turnaround time of service discovery.
the control menu for the UPnP TV is used to start or stop the UPnP TV service, and the channel field is used to change the TV channel. The power field of the control menu for the UPnP Webcam is used to start or stop the UPnP Webcam service. As shown in Fig. 6.c, when we press the show icon, the captured images will be transferred from the UPnP Webcam. 4.2. Performance evaluations To study the performance of our OSGi-based platform, we have conducted experiments with our prototype implementations. As shown in Fig. 7, we built an experimental environment with three devices. The OSGi-based platform is hosted on PC1 with Intel Duo T2250 1.73 GHz and 1.0GB RAM, and the SISUA is hosted on PC2 with Intel Duo E6300 1.86 GHz and 1.0 GB RAM. The UPnP virtual devices, the UPnP TV, and UPnP Webcam are attached on the OSGi-based platform. The PC3 with Intel P4/3.01 GHz and 1.0 GB RAM, is used to generate background traffics between PC1 and PC3. The background traffics are the number of TCP connection requests per second. In the experiment, we want to measure the execution time of each execution between the PC1 and the PC2. The execution details are described below. In the first kind of executions as shown in Fig. 8, the UPnP devices will register their services into the Service Registry, and the SA CP will retrieve these services, and then advertise them into the SLP DA. The total execution times are shown in Fig. 9. The second scenario as shown in Fig. 10, is to measure the turnaround time between the SISUA Locator and the SLP DA on the OSGi platform. The results of second scenario are shown in Fig. 11. The third execution as shown in Fig. 12 is a sequence of control command from the Controller to the UPnP TV or the UPnP Webcam. Upon receiving a control command from the Controller, the OSGi platform has to forward the
control command to the UPnP device, and then forwards the response message to the Controller. The turnaround times of each execution between the Controller and the UPnP device are shown in Fig. 13. As shown in Fig. 9, the execution time for service registry is very stable, and is not affected by the amount of background traffic. From Fig. 11, we can know that the turnaround time for service discovery will increase slightly when the amount of background traffic increases. In contrast, the turnaround time for service control is increased when the amount of background traffic increases. That is because the OSGi framework should process the messages passing between the Controller and the UPnP devices. Although the turnaround time of service control will increase when the amount of background traffic increases. In the realistic home network environment, the amount of TCP requests between the residential gateway and home appliances will be bound. However, the performance of the residential gateway will decrease when the amount of TCP requests from the external network increases. The firewall is the front line defense mechanism against intruders, and block traffic from the outside [21,22]. The firewall can use the packet filter to filter packet, and has the ability to filter or block traffic to and from a network. We can place the firewall between the external network link and the residential gateway, and the amount of TCP requests from the external network will be controlled by the firewall. Thus, with the firewall, our proposed residential gateway can provide better performance. 5. Conclusions and future works Ubiquitous computing in home networks has gone more increased attention over the past few years. We proposed an OSGi-based residential gateway to provide heterogeneous services or automatic
Fig. 10. Service discovery.
M.-X. Chen, T.-C. Tzeng / Computer Standards & Interfaces 33 (2011) 271–279
279
Fig. 12. Service control.
Fig. 13. The turnaround time of service control.
device discovery, registry, and management. The SLP SA, the DA, the SIP UA, and the UPnP control point are integrated into the OSGi-based residential gateway. We also integrated the SLP UA, the SIP UA and UPnP control interface into the SISUA. Our implementation provides easy heterogeneous services and device operation with other networks. From the evaluation results, the performance of our Gateway will decrease when the number of TCP requests increases. We think that this problem is not very serious in a home network environment. Traffics from external networks can be easily controlled by the firewall. In the future, we will extend the OSGi platform capabilities to support an intelligent digital home network security system.
References [1] JXTA(TM) Community Projects, https://jxta.dev.java.net. [2] UPnP Forum, http://www.upnp.org. [3] J. Veizades, E. Guttman, C. Perkins and S. Kaplan, “Service Location Protocol”, RFC 2165, IETF July 1997. [4] E. Guttman, C. Perkins, J. Veizades, and M. Day, “Service Location Protocol, Version 2”, RFC 2608, IETF June 1999. [5] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley and E. Schooler, “SIP: Sesson Initiation Protocol”, RFC 3261, IETF June 2002. [6] Open Service Gateway Initiative, http://www.osgi.org/. [7] H. Schulzrinne, Wu. Xiaotao, S. Sidiroglou, S. Berger, Ubiquitous computing in home networks, IEEE Communications Magazine 41 (11) (Nov. 2003) 128–135. [8] R. Shacham, S. Schulzrinne, S. Thakolsri, W. Kellerer, The virtual device: expanding wireless communication services through service discovery and session mobility, IEEE International Conference on Wireless and Mobile Computing, Networking and Communications 4 (Aug. 2005) 73–81. [9] Min-Xiou Chen, Chen-Jui Peng, Ren-Hung Hwang, SSIP: split a SIP session over multiple devices, Computer Standards and Interfaces 29 (5) (July 2007) 531–545. [10] Min-Xiou Chen, and Fu-Ju Wang, “Session Mobility of SIP over Multiple Devices”, Tridentcom 2008, Innsbruck, Austria, March 18–20, 2008. [11] P. Dobrev, D. Famolari, C. Kurzke, B.A. Miller, Device and service discovery in home networks with OSGi, IEEE Communications Magazine 40 (8) (Aug. 2002) 86–92. [12] D. Bushmitch, Wanrong Lin, A. Bieszczad, A. Kaplan, V. Papageorgiou, A. Pakstas, A SIP-based device communication service for OSGi framework, IEEE Consumer Communications and Networking Conference, Jan. 2004, pp. 453–458.
[13] C. Guiran, Z. Chuan, Matthew Y. Ma, Z. Weiguo, Z. Jingbo, Implementing a SIPbased Device Communication Middleware for OSGi Framework with Extension to Wireless Networks, International Multi-Symposiums on Computer and Computational Sciences, Vol. 2, April 2006, p. 603-310. [14] H. Schmidt, T. Guenkova-Luy, F.J. Hauck, Service location using the Session Initiation Protocol (SIP), International Conference on Networking and Services (2006) 60-60. [15] Yao-Chung Chang, Jiann-Liang Chen, Han-Chieh Chao, Sy-Yen Kuo, OSA-based service platform for all-IPv6 network environments, IEEE Journal on Selected Areas in Communications 23 (11) (November 2005) 2172–2181. [16] Wu. Chao-Lin, Chun-Feng Liao, Fu. Li-Chen, Service-oriented smart-home architecture based on OSGi and mobile-agent technology, IEEE Transactions on Systems, Man, and Cybernetics, Part C: Applications and Reviews 37 (2) (March 2007) 193–205. [17] Y. Ai, Y. Sun, W. Huang, X. Qiao, OSGi Based Integrated Service Platform for Automotive Telematics, IEEE International Conference on Vehicular Electronics and Safety, December 2007, pp. 1–6. [18] OW2 Forge: Project Info-Oscar-OSGi Framework, http://forge.objectweb.org/ projects/oscar/. [19] jSLP, http://jslp.sourceforge.net/. [20] SIP Communicator, http://sip-communicator.org/. [21] A. Householder, K. Houle, C. Dougherty, Computer attack trends challenge Internet security, Computer 35 (4) (Apr 2002) 5–7. [22] Olalekan Adeyinka, Internet attack methods and internet security technology, Second Asia International Conference on Modelling & Simulation, May 2008.
Min-Xiou Chen is an Assistant Professor of the Department of Computer Science and Information Engineering, National Dong Hwa University, Hualien, Taiwan, ROC from 2008. Prof. Chen received the B.S. degree in Computer and Information Science from Tung Hai University, Tai-Chung, Taiwan, ROC in 1996, and M.S. and Ph.D. degrees in Computer Science and Information Engineering from National Chung Cheng University, Chia-Yi, Taiwan, ROC in 1998 and 2005, respectively. In August 2005, Prof. Chen joined the faculty of the Department of Computer Science and Information Engineering, Chung Hua University, as an Assistant Professor. Since August 2008, Prof. Chen joined the Department of Computer Science and Information Engineering, National Dong Hwa University. His research interests include wireless communication, VANET, home network, sensor network and resource management in next-generation personal communication system.
Tze-Chin Tzeng received the B.S. and M.S. degrees in Computer Science and Information Engineering from the Chung-Hua University, HsinChu, Taiwan. He works as an engineer at the Network Benchmarking Laboratory, Nation Chiao Tung University, HsinChu, Taiwan. He is currently working on voice/video over IP, NAT traversal, network content security, and real flow application.