The integration of home-automation and IPTV system and services

Computer Standards & Interfaces 31 (2009) 675–684

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 e v i e r. c o m / l o c a t e / c s i

The integration of home-automation and IPTV system and services Mark Umberger a,b,⁎, Iztok Humar b, Andrej Kos b, Jože Guna b, Andrej Žemva b, Janez Bešter b a b

GOAP d.o.o., Ulica Klementa Juga 7, 5250 Solkan, Slovenia Faculty of Electrical Engineering, University of Ljubljana, Tržaška ul. 25, 1000 Ljubljana, Slovenia

a r t i c l e

i n f o

Article history: Received 20 July 2007 Received in revised form 26 August 2008 Accepted 28 September 2008 Available online 26 October 2008 Keywords: Home automation IPTV Gateway IP network User interface

a b s t r a c t In this paper we propose the integration of a home-automation system and its services (HASS) with an IPTV system and its services (IPTVSS) to enable convergence at the network-technology and user-interface levels. The convergence at the network-technology level was achieved by using the Internet protocol (IP), and therefore both integrated systems have to provide IP connectivity. To enable communication between the HASS and the IP-based services, we have implemented the WebService/Konnex gateway. The IPTVSS are IP based; therefore, an easy convergence at the network-technology level is possible. The convergence at the user-interface level was achieved by a hardware and software user-interface implementation. © 2008 Elsevier B.V. All rights reserved.

1. Introduction With the advent of the digital era, the role of data-broadcasting systems and services, such as the IPTV system and its services (IPTVSS), in providing users with value-added information via their TV sets has become important. Meanwhile, home-networking systems and services, such as the home-automation system and its services (HASS), which control heterogeneous devices, are now in the spotlight [1]. The theory of integrating various systems and services opens the door wide to a number of discussions on new, converged network services [2], which is why in this paper we present an implementation of HASS and IPTVSS integration. With the development of low-cost electronic elements, HASS is gradually migrating from the company sector to the consumer market. Market research has shown that most future living environments will be equipped with this type of system and services [2]. There are a number of systems currently available on the market that can automate various processes, e.g., heating, ventilating and air-conditioning systems, using different communications standards; the most frequently used of which are Konnex [3], LonWorks [4], X-10 [5] and BAC net [6]. Our study is based on the Konnex standard, which, in our opinion, is the best, because of its flexibility and advanced services; it is also the most commonly used such system in Europe. HASS also provides Internet connectivity, thereby enabling users to remotely control their HASS applications using home-automation servers. These home-automation servers have a variety of user interfaces; however, these interfaces are usually proprietary, and

⁎ Corresponding author. E-mail address: [email protected] (M. Umberger). 0920-5489/$ – see front matter © 2008 Elsevier B.V. All rights reserved. doi:10.1016/j.csi.2008.09.012

thus program intervention at the user interface is either impossible or very limited. Generally speaking, the term IPTV refers to a system whereby digital television services are delivered to the home using the Internet protocol over a suitable underlying network infrastructure. Today, IPTVSS technologies and the available broadband bandwidths have now evolved to the point where broadband access providers can effectively enter the market for delivering TV programs to their customers [7]. In the broader sense, IPTV comprises the following: (1) the live IPTV video service (live television), which represents one of the most common IPTV services; (2) the video-on-demand service (VoD), which allows users to listen to audio or view video content when they want; (3) the personal video-recording service (PVR), which allows users to record and timeshift their video content; and (4) the electronic program-guide service (EPG), which offers additional content information and can be used to trigger the IPTV, VOD and PVR services. Although both the IP and Konnex networks are based on the OSI reference model, the technologies involved are not the same because different physical media and communication protocols are used. Furthermore, various, and mostly non-uniform, user interfaces for different devices are used, which can be confusing for the user. In general, user interfaces can be divided into two distinct groups: hardware user-interfaces and software user-interfaces. HASS mostly uses personal computers with a mouse, a keyboard and a display as the hardware user-interface and the control program application with a graphical user interface as the software user-interface. On the other hand, the IPTVSS hardware user-interface generally consists of a settop box with a remote controller connected to the TV set. The IPTVSS software user-interface is usually web based and specifically designed for the TV environment. The set-top box works as a client, enabling

676

M. Umberger et al. / Computer Standards & Interfaces 31 (2009) 675–684

Fig. 1. HASS and IPTVSS integration.

content streaming from the IPTV system, where the complete program application with a graphical user interface is installed. Since HASS and IPTVSS use different network technologies and user interfaces, we propose and have implemented an integrated system that allows convergence at the network-technology level, based on the IP network, and convergence at the user-interface level, providing common services, as shown in Fig. 1. The user interface of the implemented system consists of a common hardware and software user-interface. 2. Related work To fulfill the requirements for convergence at the IP networktechnology level, HASS and IPTVSS have to provide IP connectivity. IPTVSS is already based on the IP standard and thus is ready for convergence at the network-technology level. Since HASS is not IPbased we first reviewed the related works focused on HASS and IPbased network integration. In order to integrate these two completely different systems, i.e., HASS and IPTVSS, and to provide convergence at the user-interface level, we also studied the related works enabling these requirements. 2.1. IP network technology convergence In the IP-based environment the Simple Network Management Protocol (SNMP) [8] can be used to control and monitor different HASS devices. However, this approach requires additional processing and can have a negative effect on the overall performance. Another approach, discussed in Ref. [9], suggests that Java-based applications could be used to access the Konnex network, which provides all the benefits of the Java-based platform, most notably hardware independence. However, a Java virtual machine requires high-performance hardware. The approach described in Ref. [10] involves the integration of HASS and IP-based networks using the OSGi service framework, defined in the OSGi specification [11], and which is also Java based. In addition to all the advantages and disadvantages of the Java platform, practical experience with OSGi has shown that service interoperability becomes very complex as soon as an unknown configuration of services in the target environment is considered. Another possible obstacle to using OSGi is the relatively high license fees being charged. The OPC [12] specification is another viable solution. However, a study [13] has shown that OPC

interfaces increase security risks in web-based applications and do not allow access to OPC servers from non-Windows devices. To overcome this problem a middleware framework for combining OPC and Web Services was proposed. However, in addition to the high price of the hardware providing the OPC functionality, this approach requires more high-performance hardware providing Web Service functionality, which additionally increases the complexity of the installation. Similarly, approach [14] uses a LonWorks HASS to communicate with the remote server using a Web Services technology. After considering all the benefits and drawbacks of the abovementioned approaches we decided to use Web Services technology to communicate between the Konnex and IP-based networks using a single device called the WebService/Konnex gateway. 2.2. User-interface convergence In Ref. [15] authors discuss the transmission of digital MPEG-4 video over the OSGi framework. Their evaluation of a prototype showed that the most critical factor is the encoding time, which results in the use of effective hardware encoders that are usually inappropriate for use in an IPTVSS. An additional problem is that OSGi is not a suitable middleware solution for IPTV. Interactive digital TV (IDTV) and OSGi integration issues were also addressed in Refs. [16–18], with the focus on different IDTV middleware platforms, such as the MHP (Multimedia home platform), the ACAP (Advanced common application platform), the OCAP (Open cable application platform) and the DASE (Digital TV application software environment). The principles involved in these approaches are interesting, but a serious implementation example is lacking. That is why another similar improved solutions enabling the integration of the MHP IDTV middleware and the OSGi framework has been realized [19,20], enabling collaboration between the OSGi platform, installed on a Residential Gateway, and the MHP, installed in a settop box. In general, set-top boxes are not just the decoders for a digital television broadcast; they are also suitable platforms for supporting the execution of interactive applications. These approaches enable the control and monitoring of multimedia and home-automation services using a TV set and a remote control, and as a result convergence at the user-interface level is achieved. A potential problem with the MHP approach is that the MHP is Java based and as such requires a higher level of hardware performance from the set-top boxes, which imposes additional costs and so might be unacceptable to service providers.


Furthermore, the applicability of the MHP is decreasing rapidly, and this standard is unlikely to be as dominant in the future. A better solution than the MHP is the ACAP middleware. Ref. [21] presents the integration of the ACAP middleware with an UMB (universal middleware bridge), used for the interoperability of home-network devices (i.e., HASS), and both are based on Java. Although the ACAP is used more often than MHP, the problems mentioned above remain the same.

677

3. Standards/protocols and interfaces of HASS and IPTVSS The implemented system connects two different environments, i.e., the HASS and IPTVSS, and uses several different standards/ protocols. The communications among the elements involve the use of different interfaces. To understand the integration between the various elements we separately introduce standards/protocols and interfaces from individual parts.

2.3. Our novel approach 3.1. HASS standards/protocols and interfaces To overcome the above problems we propose and have implemented a system with a completely IP-based architecture that is divided into the operator side (server head-end side), and the network and user (client) side. A unique feature of this architecture is that the Central Server executing middleware for the HASS is located only on the server side; all the service logic and the execution of services are located on the operator side. Therefore, no highperformance hardware is needed on the user side, which is much more acceptable to the service providers and to the users. By using this approach all the systems and services can be controlled from a single point, which is a great advantage from the operator's point of view. This architecture is also more flexible when it comes to the integration of new and more complex IP-based services, where all the required work can be carried out on the server side and new services can be integrated independently of the software used. The Central Server also makes possible an integration with any IPTVSS middleware by using the Web-Services approach. Another novel approach in this paper is the Konnex/WebService gateway, which enables a connection between the HASS and the Central Server without any additional licenses being required (i.e., OPC) by using a single hardware device. Using this gateway, convergence at the network-technology level can be achieved. The implemented user interface enables the monitoring and control of an integrated system by using the TV set and a remote controller. The advantage of this approach is that all the data required by the user interface is received from the operator (on the server side), and therefore all the implementations and upgrades of the user interface can be handled by the operator.

In terms of the HASS standards, the focus of our study is on the Konnex standard. The standard was designed by merging three leading standards from the area of home automation, (1) BatiBUS [22], (2) EIB [23] and (3) EHS [24], into a new Konnex association. It is derived from the EIB standard communication-protocol stack and extended with additional physical layers, configuration modes and application experience gained through the use of the BatiBUS and EHS standards. The EIB protocol is based on the ISO/OSI reference model, and the use of the CSMA/CA access mechanism has greatly improved the credibility and utilization rate of the bus communication [25]. The Konnex standard supports three different configuration modes, differing with regard to the system complexity: (1) S-, (2) E- and (3) A-mode. The S- and E-mode enable the Konnex network to be configured using a specific program tool, ETS3. The A-mode makes it possible for the user to have an independent configuration. The Konnex standard allows communications through a variety of communication media, including TP-0 (twisted-pair type 0), TP-1 (twisted-pair type 1), PL-110 (power-line network, 110 kHz), PL-132 (power-line network, 132 kHz), RF (radio frequency 868 Mhz), and Ethernet (Konnex-over-IP). Our approach uses HASS based on the Smode and communication media type TP-0. The S-mode was used because of the highest level of functionality provided by the systems working on this mode and the TP-0 communications media was used because it represents the most frequently used communications media for Konnex HASS. With no barrier the implementation can involve using another configuration mode and communications media.

Fig. 2. IPTV services protocol stack.

678


The interface-level integration of HASS with IP-based networks represents the most important Konnex network interface and has already been introduced in the review of related works, provided in the previous section. The Konnex network also includes different user interfaces, e.g., touch screens, remote controllers, PCs and PDAs. All these user interfaces make it possible to control and monitor the entire home-automation system from a single point. However, some of these user interfaces are connected straight to the Konnex network and do not provide a typical, server–client Internet logic, so the integration with non-Konnex-based user interfaces is very limited. In spite of this some of them satisfy the server–client Internet specification, so the integration with other IP-based user interfaces might be possible. Nevertheless, these user interfaces are strictly dedicated to HASS services, and therefore no, or very few, additional services can be controlled and monitored by using these user interfaces on their own. 3.2. IPTVSS standards/protocols and interfaces In terms of architecture, the IPTV system consists of the service segment (the server head-end side), the user-premises segment (the user side) and the network segment. The service segment includes the IPTV middleware server equipment, the video servers (providing the VoD services) and the video encoders (providing the live IPTV services), which represent the most typical IPTV elements. The broadband network connection terminal equipment and the IPTV set-top box are located in the user-premises segment. The function of the set-top box is to integrate the digital broadband communications interfaces, e.g., Ethernet, with the classical television interfaces, e.g., composite video, SCART and HDMI, in a single device, thus representing a new type of converged terminal equipment that is specially designed for IPTV services. The purpose of the set-top box is to receive the broadband multimedia content (usually in MPEG-2 or MPEG-4 format) and to display it on the TV set. The set-top box includes an embedded operating system, a browser and a real-time multimedia player. The network segment connects the service segment and user-premises segment and provides the basic network services. As shown in Fig. 2, the IPTV protocol stack is based on the TCP/IP stack. However, due to the specific properties of the IPTV traffic and services, e.g., real-time services and strict QoS constraints, additional application-layer protocols are required. The VoD service typically utilizes two separate communication sessions: one for video signalization and one for video data. The former, which is used to describe the content and to convey user commands, e.g., play/pause, stop, fast forward and rewind, is transported by the Real-Time Streaming Protocol (RTSP). The latter is transported by the Real-Time Transport Protocol (RTP). In conjunction with RTP the Real-Time Transport Control Protocol (RTCP) can be used. It is mostly employed to monitor the RTP flow and to gather QoS information. Compared to the actual RTP video data, the RTSP video signalization data represents only a small fraction of the total amount of data (typically less than 1%). However, it is of vital importance that the RTSP video signalization data is received intact. On the other hand, the RTP video data is much more prone to delay. Therefore, on the transport layer the TCP is used for transporting the RTSP video signalization data and UDP for the RTP video data itself. VoD services typically employ unicast communications, whereas live IPTV services employ multicast communications. The protocol stack for live IPTV services is also somewhat different, using multicast protocols for service requesting, e.g., the Internet Group Management Protocol (IGMP) and the UDP for actual data transmission. 4. Integrated system architecture The architecture shown in Fig. 3 explains the principle of our integrated system, consisting of (A) the server-side segment, (B) the interconnecting network and (C) the user side.

4.1. Server-side segment The equipment needed to perform integrated services such as the Central Server and the IPTV system is located on the server side. The Central Server comprises a web server and the database elements. The main function of the web server is to serve the graphical user interface and to implement the application logic, including an interface for database access. Its most important function is its capacity to integrate IPTVSS and HASS at the software user-interface levels. This is achieved by using specifically designed APIs to integrate both GUI and HASS gateway enabling monitoring and control of the integrated system on demand. The Central Server also provides APIs, allowing for the integration of external services (such as data collection for e-health [26]). The application logic on the web server is also responsible for saving the device statuses and scenarios occurring in the Konnex network. This has to be done because of the properties of the Konnex technology. Device statuses and scenarios in the Konnex network are represented as different group addresses with associated values. These values can be modified by using different group address services. As it is impossible to make a read-group services request on every device or scenario, the application logic saves all the group addresses and their values appearing in the database of the Konnex network. The database consists of different parts providing data about users, rooms, interfaces, interface types, interface statuses and user permissions. The function of the IPTV system is to control and to provide live and on-demand multimedia services. 4.2. Network segment The network segment ensures the connection between the server and the user sides using a broadband access network. It also enables QoS, an appropriate level of security and multicast capabilities for IPTVSS. As can be seen from Fig. 3, the proposed architecture is based on the telco approach. Its major advantages are providing central management of the integrated system, enabling the integration of external services like IPTVSS and allowing for central upgrading from the providers. Its major disadvantage is the necessity for communications flows going out of the home environment, in the case of HASS control. Nevertheless, we opted for this solution since HASS is typically an independent system and allows the manual control of devices by itself. In our opinion the advantages of the proposed architecture outweigh the disadvantages, especially for telco providers. 4.3. User-side segment The user-side segment includes the HASS, the gateway and the user terminal equipment. The HASS combines different homeautomation devices, e.g., sensors, actuators, regulators, switches, and household appliances. Its functions are the automatic control of a variety of processes (e.g., heating, cooling, lightning, shutters, and household appliances) and scenarios (e.g., lights 70%, shutters down and washing-machine off). The automatic execution of different processes and scenarios in the Konnex network is ensured by the interchangeable operation of home-automation devices, enabled by using group addresses, (e.g., in order to allow for the automatic operation of the lightning system, the sun-radiation sensor, the presence sensor and the lightning actuator have to be in the same group address) and performing different group-address services. The main function of the gateway is to enable the Konnex-based HASS two-way communications with the remote Central Server using IP/ web technologies. The user-terminal equipment includes a set-top box, a remote controller, a TV, a PDA and a PC, representing the hardware user-interface of the integrated system. The main function


679

Fig. 3. Integrated-system architecture.

of the user-terminal equipment is the control and monitoring of the integrated system. 5. Results The main results of our work are represented in (A) the implementation of the WebService/Konnex gateway, providing convergence at the network-technology level; (B) the implementation of the Central Server, enabling the integration of the HASS and the IPTVSS; and (C) the implementation of the hardware and software user-interfaces, providing convergence at the user-interface levels. A detailed description of the standards/protocols and interfaces used in integrated systems is discussed in section D. In order to better explain the workings of the implemented system, the last part of this subsection, E, is dedicated to describing the data flows in cases of the interaction between the user and the HASS and the interaction between the user and the IPTVSS.

5.1. Implementation of the WebService/Konnex gateway Fig. 4 shows that our WebService/Konnex gateway consists of two separate parts. The first is the Konnex, and the second is the Web Service gateway. The hardware implementation of the actual WebService/Konnex gateway is shown in Fig. 5. 5.1.1. Konnex gateway The Konnex gateway enables two-way communications between the Konnex network and an RS-232 serial port and a two-way transformation of the native Konnex services, called application-layer services and transport layer services, into the ASCII text format. The Konnex application layer provides two types of multicast-communication relationship services, called the write-group service and the read-group service. The right-hand column in Table 1 shows the structure of these application-layer services in the Konnex network, and the middle column in Table 1 shows the transformation of these

Fig. 4. WebService/Konnex gateway.

680


Fig. 5. Hardware implementation of WebService/Konnex gateway.

services into the ASCII text format. The write-group service includes a write_group_request APDU (application layer program data unit) and does not contain a write-group response APDU in the application layer. The confirmation of the write_group_request is made by the T_groupdata service in the transport layer. A read-group service includes a read_group_request APDU and a read_group_response APDU in the application layer. Therefore the Konnex gateway enables the transformation of three types of APDU, which correspond to an appropriate application-layer service and one TPDU (transport layer program data unit) that corresponds to the T_groupdata service in the transport layer. The APDU is made of a different number of bytes depending on the service used and has a minimum length of at least nine bytes. The Konnex gateway always checks just the 7th and the 8th bytes from the left in the Konnex telegram. As shown in Table 1, the 7th byte (E1) is represented in binary as 11100001. The first bit denotes whether the destination address is a group (1) or a physical address (0) and the last four bits represent the type of value of the group address used (1 bit, 1 byte, 2 bytes, etc.). Therefore, if the first bit

is 1, the Konnex gateway starts checking the 8th byte, detecting the service as multicast, broadcast, one-to-one connectionless oriented or one-to-one connection oriented. In the example shown in Table 1, the 8th byte is represented as 00hex, which means that the service is multicast. The 9th byte in the Konnex telegram represents the application-layer service type. The value 80hex represents a writegroup request service, the value 00hex represents a read-group request service and the value 40hex represents a read-group response service. The bytes after the 9th byte are used only when the type of value used is 1, 2 or 3 bytes, or more. 5.1.2. Web Service gateway The Web Service gateway enables two-way communications between the RS-232 serial port and the IP network by using the Web Services protocol and a two-way transformation of the ASCII text format to XML format. As shown in Table 1, the Web Service gateway enables the transformation of two types of services based on the Konnex application layer, i.e., the read-group service and the write-

Table 1 XML/ASCII/KONNEX data structure. XML

ASCII

Konnex appl. layer services

bWriteFunctionValueN bfunction address=“0/0/1”N1b/functionN b/WriteFunctionValueN

W0/0/1=1

20 BC 11 01 00 01 E1 00 81

bWriteFunctionValueResponseN bfunction address=“00/0/01”N1b/functionN b/WriteFunctionValueResponseN

N00/0/001=1

bReadFunctionValueN bfunction address=“00/0/07”/N b/ReadFunctionValueN

R0/0/7

29 BC 11 01 00 01 E1 00 00

bReadFunctionValueResponseN bfunction address=“00/0/07”/N 1438b/functionN b/ReadFunctionValueResponseN

N00/0/007=1438

29 BC 11 01 00 01 E1 00 40 0C FB


681

Fig. 6. Entry screen.

group service, to the XML format. The structure of the services based on the XML format is shown in the left-hand column in Table 1. The application was implemented using Visual basic [27]. 5.2. Central Server implementation The Central Server enables interconnection of all the elements involved in the presented system. It provides communication to the WebService/Konnex gateway, the database and the user interface. The services (e.g., home automation) or their parts (e.g., live IPTV and VOD service triggers) are registered in the Central Server, where the service logic is implemented. The Central Server was implemented using the Microsoft Internet Information Server (IIS) with Active Server Pages (ASPs) and MySQL as the database. 5.3. User-interface implementation The user interface consists of hardware and software components. The former are physical components and the latter are mostly different graphical user interfaces. 5.3.1. Hardware user-interface The hardware user-interface consists of several different types of terminal equipment, such as a TV set with a set-top box and remote controller, a personal computer, a PDA and a touch panel. The most important is the set-top box in combination with a simple remote controller, to provide access to the new, converged services and the well-known TV-like experience. The proposed pilot set-top box is a PC-based platform (VIA Epia miniITX platform), while Windows XP is used as the operating system. For the control, a universal remote controller operating via an IR interface is used. The set-top box can be connected to the TV set either via analogue (SVHS, composite) or digital (VGA, DVI) interfaces. In our scenario we used a high-quality digital plasma display with a digital interface. The set-top box acts

entirely as a client device and has two main purposes. The first is communication with the Central Server and the interpretation and visualization of the data in the form of graphical user interface. The second is the visualization of the multimedia content using the embedded Windows Media Player (for WindowsMedia content) and a VideoLan player (for MPEG-2 and MPEG-4 content). 5.3.2. Software user-interface The implemented software part of the user interface is entirely web and Flash based. It is, therefore, completely hardware independent, providing the underlying hardware supports web and Flash applications and has IPTV-video-rendering capabilities. The implemented software user-interface provides control over the integrated system by using a specially designed graphical user interface, as shown in Figs. 6–8. Fig. 6 shows the entry screen, where the user can choose between the HASS and IPTV services. Fig. 7 shows an example of the live IPTV video service. An example of the home-automation control services is shown in Fig. 8. It should be noted that the IPTV services are seamlessly integrated with the other services to provide a classic TV-like experience. The video content is constantly being played in the background, whereas the other services can be accessed using the concept of transparent floating menus over the video plane. 5.4. Standards/protocols and interfaces used in the implemented system The aim of this section is to present information about the standards/protocols and the interfaces used in the implemented system. The interfaces are presented as white squares and the standards/protocols are presented as grey arrows, in Fig. 9. From the interfaces point of view, Fig. 9 shows the interfaces that enable the physical transformation between two different mediums and user interfaces (hardware and software), enabling an interaction between the user and the integrated system. As is clear from Fig. 9, the

682


Fig. 7. Live IPTV service.

interfaces enabling the physical transformation between two different mediums are the WebService/Konnex gateway and the home router. The former provides the two-way transformation of the Konnex physical medium to the Ethernet medium, and the latter provides the two-way transformation of the different access network media (i.e., fiber optic, cable, and xDSL) to the Ethernet medium. As shown in Fig. 9, three different types of hardware user-interfaces can be used in an integrated system. The most appropriate option is a set-top box, together with a remote controller and a TV set; all devices that the user is likely to be familiar with. However, to achieve user flexibility, PC and PDA hardware interfaces can also be used. The software user-

interface is implemented with Flash technology, installed on every type of hardware user-interface individually. From the standards/protocols point of view, Fig. 9 shows the standards/protocols used for communications between different systems and standards/protocols used to provide the requested services. As seen in Fig. 9, the data from/to the HASS, which uses the standardized communication protocol EIB, can be transmitted from/to the Central Server using the SOAP/XML/HTTP communication protocols at the application layer and TCP at the transport layer. By using these protocols, all the services from the HASS can be provided. Communications between the IPTV system and the Central

Fig. 8. Home-automation control services.


683

Fig. 9. Integrated-system standards/protocols and interfaces. (For interpretation of the references to colour in this figure legend, the reader is referred to the web version of this article.)

Fig. 10. Data flow. (For interpretation of the references to colour in this figure legend, the reader is referred to the web version of this article.)

684


Server are enabled by using the WebService/HTTP or WebService/ HTTPS communication protocols. As shown in Fig. 9, the standards/ protocols used to provide IPTV services are RTP/UDP, to provide video-on-demand services; multicast, to provide live-IPTV services; and RTSP/TCP, to provide signalization. 5.5. Data flow Fig. 10 presents the data flow in the case of an interaction between the user and the HASS, and in the case of an interaction between the user and the IPTVSS. The interaction between the user and the HASS is illustrated with a simple example, where the user is switching the light ON and OFF. The data flow for this example is represented by the grey arrows in Fig. 10. The interaction starts when the user pushes the button on the remote controller and sends the appropriate command to the set-top box. Since the set-top box operates as a client connected to the Central Server, the command changes the state in the database for that particular light. The Central Server then sends the write-request service using the Web Services protocol to the WebService/Konnex gateway, which transforms the request to an appropriate command on the Konnex network. When the light changes its state, the Konnex network sends a confirmation to the WebService/Konnex gateway and sends the response service to the Central Server using the Web Service. The Central Server now confirms the change in the device's state in the database. In the next step, the Central Server changes the state on the graphical user interface. The interaction between the user and the IPTVSS is illustrated with an example, where the user is changing channels with the remote controller. The data flow for this example is represented by the white arrows in Fig. 10. The interaction starts when the user pushes the button on the remote controller and sends the command to the settop box. The set-top box then forwards this command to the Central Server, which changes the channel on the IPTV system. The IPTV system then starts streaming the selected content to the set-top box. 6. Conclusions In this paper we proposed and implemented a system enabling the integration of the HASS and the IPTVSS with a completely IP-based architecture, where all the service logic and the execution of services are placed on the operator side, which is very acceptable to the service providers because of the much better control and monitoring and also because of the easier service intervention in the case of problems. Therefore, both the implemented Central Server, representing the executing middleware for the HASS, and the IPTV system, representing the middleware for the IPTVSS, are located on the operator side. This architecture is also more flexible in terms of the integration of new and more complex services, where all the required work can be done on the operator side. The HASSs are based on the Konnex standard, and therefore the convergence on the IP network has to be provided. This was achieved by implementing the Konnex/WebService gateway in a single hardware device, and therefore no additional licenses, i.e., OPC, or hardware are needed. A combination of the HASS and the IPTVSS allows the creation of new, converged services, which is why a common user interface is required, and so the convergence at the user-interface level has to be provided. In an implemented system, the hardware user-interfaces are a TV, a set-top box and a remote controller, all appliances that the user is familiar with. The software user-interface of the integrated system is a software application with a graphical user interface. The advantage of this approach is that all the data required by the user interface is received from the operator, and therefore all the implementations and upgrades of the user interface can be entirely handled by the operator.

Based on the approach presented in this paper, we propose the following directions for future work: (1) the integration of additional IP-based telephone services [28] could additionally contribute to our implemented system architecture and (2) the integration of the HASS and IPTVSS based on IMS/NGN architecture could be developed from our implemented system, representing new SIP-based services, which could be very interesting for service providers in the future. References [1] Yu-Seok Bae, Bong-Jin Oh, Kyeong-Deok Moon, Sang-Wook Kim, Architecture for interoperability of services between an ACAP receiver and home networked devices, IEEE Consumer Electronics 52 (1) (2006) 123–128. [2] A.Z. Alkar, U. Buhur, An Internet based wireless home automation system for multifunctional devices, IEEE Consumer Electronics 51 (4) (2005) 1169–1174. [3] Konnex, http://www.konnex.com, (online, 10.4.2007). [4] LonWorks, http://www.echelon.com, (online, 12.4.2007). [5] X-10, http://www.x10.com, (online, 3.2.2007). [6] BACnet, http://www.bacnet.org, (online, 19.7.2008). [7] A. Yarali, A. Cherry, Internet Protocol Television (IPTV), Proc. IEEE region 10 TENCON 2005, pp. 1–6. [8] M. Kunes, T. Sauter, Fieldbus–Internet connectivity: the SNMP approach, IEEE Transactions on Industrial Electronics 46 (6) (2001) 1248–1256. [9] R. Ott and H. Reiter, Connecting EIB components to distributed Java applications, in: Proc. ETFA 99, IEEE International Conference on Emerging Technologies and Factory Automation, vol. 1 18–21 October 1999, 23–26. [10] S.K. Tso, B.L. Luk, W.H. Choy, K.P. Liu, C.S. Chow, K.F. Leung, G. Lee, F. Yau and C.W. Lam, An intelligent networking and automation system for home and SOHO environments, in: Proc. ACCA 2003, The Fourth International Conference on Control and Automation 10–12 June 2003, 88–92. [11] Th. Zahariadis, K. Pramataris, Multimedia home networks: standards and interfaces, Computer Standards & Interfaces 24 (5) (2002) 425–435. [12] Xu Hong, Wang Jianhua, Using standard components in automation industry: a study on OPC Specification, Computer Standards & Interfaces 28 (4) (2006) 386–395. [13] Shengwei Wang, Zhengyuan Xu, Jiannong Cao, Jianping Zhang, A middleware for web service-enabled integration and interoperation of intelligent building systems, Automation in Construction 16 (1) (2007) 112–121. [14] V. Kapsalis, K. Charatsis, M. Georgoudakis, E. Nikoloutsos, G. Papadopoulos, A SOAP-based system for the provision of e-services, Computer Standards & Interfaces 26 (6) (2004) 527–541. [15] D.A. Tkachenko, A.V. Lagunov, V.V. Trofimov, E.A. Andrievsky and N.V. Kornet, Usage of MPEG-4 video on OSGi devices, In: Proc. ISCE 2006, IEEE Tenth International Symposium on Consumer Electronics 2006, 1–6. [16] Tkachenko, N. Kornet, A. Kaplan, Convergence of iDTV and home network platforms, In: Proc. CCNC 2004, IEEE First Consumer Communications and Networking Conference 5–8 January 2004, 624–626. [17] D. Tkachenko, N. Kornet, A. Dodson, Li Luyang, R. Khandelwal. A framework supporting interaction of iDTV applications and CE devices in home network, In: Proc. CCNC 2005, IEEE Second Consumer Communications and Networking Conference 3–6 January 2005, 605–607. [18] D. Tkachenko, N. Kornet, A. Lagunov, D. Kravtson, A. Kurbanov, R. Khandelwal, Li Luyang, A possible extension for iDTV platform to support interactions with home appliances, In: Proc. CCNC 2006, IEEE 3rd Consumer Communications and Networking Conference 8–10 January 2006, 228–232. [19] M.R. Cabrer, R.P.D. Redondo, A.F. Vilas, J.J.P. Arias, J.G. Duque, Controlling the smart home from TV, IEEE Consumer Electronics 52 (2) (2006) 421–429. [20] Ming-Chien Yang, Norman Sheng, Brandon Huang, Jethro Tu, Collaboration of settop box and residential gateway platforms, IEEE Consumer Electronics 53 (3) (2007) 905–910. [21] Yu-Seok Bae, Bong-Jin Oh, Kyeong-Deok Moon, Sang-Wook Kim, Architecture for interoperability of services between an ACAP receiver and home networked devices, IEEE Consumer Electronics 52 (1) (2007) 123–128. [22] BCI — BatiBus Club International, http://www.batibus.com, (online, 10.11.2006). [23] EIB — EIB association, http://www.eiba.com, (online, 10.11.2006). [24] EHS — EHS Asociation, http://www.domotics.com/homesys/Ehsa.htm, (online, 17.11.2006). [25] S. Yao, M. Wu, Y. Liu, P. Yang, Research on EIB and Development of Switch Module, Proc. IEEE International Conference on Industrial Informatics 2006, pp. 1241–1244. [26] I. Pavlovic, D. Miklavčič, Web-based electronic data collection system to support electro-chemoterapy clinical trial, IEEE Information Technology in Biomedicine 11 (2) (2007) 222–230. [27] Microsoft Visual Basic, http://msdn2.microsoft.com/en-us/vbasic/default.aspx, (online, 10.10.2006). [28] U. Sedlar, L. Zebec, J. Bester, A. Kos, Bringing click-to-dial functionality to IPTV users [web services in telecommunications, part II], IEEE Communication Magazine 46 (3) (2008) 118–125.