AN INTEGRATED SOLUTION FOR HOME AUTOMATION
G. Giorgetti1, E. Gambi2, S. Spinsante3, M. Baldi3, S. Morichetti3, I. Magnifico1
1
AUTOMA Srl, ITALY, 2Università Politecnica delle Marche, ITALY, 3ArieLAB Srl ITALY
ABSTRACT
The increasing diffusion of home area networks (HANs),
intended for the delivery of multimedia contents (e.g. TV
programs, movies, music) as well as home automation data
(e.g. household appliances, lighting and surveillance
controls), represents a new challenge for networking.
However, at present, most of the available domotic and
building automation solutions provide single answers to the
market requirements, and their heterogeneousness makes
very hard an integration process. In this paper, a project for
an integrated solution is presented, based on both
commercial and customized devices developed ad-hoc.
Since the convergence of many traditional services over IP-
based infrastructures drastically increases the amount of IP
data traffic to be delivered to the users, questions about the
Quality of Service management arise and must be taken into
account.
Index Terms— Domotic automation, building automation,
multimedia home systems, Quality of Service.
1. INTRODUCTION
Modern houses are requested to be provided with digital
control systems for functional services, like household
appliances, lighting and surveillance. Moreover, digital
entertainment contents must be delivered in each single
room, as, for example, digital radio and television services,
movies, music and others. Many standards have been
approved for the exchange of home automation data, and
industrial protocols can also be adapted to fit home
automation applications. All these protocols can be used for
short-distance and low-cost connectivity of sensors and
actuators. However, when considering the integration of
home automation services with multimedia services over IP
based networks, gateways must be provided, able to
interface and adapt home automation data transport to IP-
based networks, in order to allow an easy management of
the connected devices, both from the home internal network
and from external networks [1], [2]. In this integrated
scenario, Quality of Service (QoS) becomes a fundamental
issue when several streams, carrying both control and
entertainment data, with different time and rate
requirements, must be transferred over a local area network
comprising heterogeneous devices [3]. In this paper, we
present the project of a Home Area Network, called WENO
Project, in which entertainment and home automation
services must coexist, in order to provide all users with
unified access stations for either entertainment applications,
the delivery of home data (such as video surveillance
streams), and the control of domestic facilities.
2. PROJECT DESCRIPTION
The system architecture we propose must satisfy two major
requirements:
i) the need for a high speed communication bus able to
deliver high quality services, like video entertainment, video
interphone, and IP telephony;
ii) the implementation of low cost local nodes used for
sensoring and control execution.
The first requirement is satisfied through the adoption of an
Ethernet bus that interconnects the system control blocks. A
five-port switch represents the core of the interconnection
structure, concentrating all the communications towards the
System Server, that allows a centralized management of the
whole network. In its turn, the System Server may be
remotely controlled and configured via Internet, by means
of a web-based application, being interfaced towards a
communication provider over an ADSL connection. From a
functional point of view, the system may be divided into
three sub systems:
1) room control;
2) room and external communication;
3) entertainment signals delivery.
As a matter of fact, an XN-Player (XeNo-Player) is
responsible for the delivery of multimedia contents to the
users, controlled by a sort of Electronic Program Guide and
Selection, that allows to transmit the programs selected by
the users. At the same time, users are equipped with an
IPTV player and a TV monitor. Communication among
rooms and towards the external is ensured by the
implementation of an IP Telephony Server, interfaced
through the System Server with the ADSL link. The
communication subsystem includes an external video
interphone, implemented by means of a device located
outside the user’s premise, and equipped with a
videocamera and bidirectional audio. The device can
communicate over the Ethernet link with an internal “twin”
device, provided with an LCD monitor. The presence of this
stand alone receiver, usually located near the main entrance
door, is required by the users, but, according with the
proposed architecture, any Room Board, equipped with a
monitor, may interface the external video interphone. The
Room Boards (XN-CPU) are able to collect all the
communications originating in a room towards the System
Server, for remote monitoring purposes.
Fig. 1 – Block scheme of the proposed system
Inside any room, the requirement of controlling sensors and
actuators is satisfied through the adoption of a low speed,
but very robust, communication bus. The CAN bus was
selected as the best suited transmission technology, due to
its high transfer rate and the low cost of enable nodes,
mainly due to the availability on the market of
microcontrollers implementing the CAN protocol together
with its physical interface. As a consequence, any Room
Board implements an Ethernet interface to communicate
a) b)
CAN
bus
Fig. 2: Realized boards of XENO Project
with the System Server, and a CAN Interface to monitor the
Local Nodes. The Local Nodes provide room monitoring
functions and command execution, like presence monitoring
and light switch on/off, but also external light intensity
sensing and internal light intensity variation. With the aim
of making the whole system more robust against unexpected
Room Board switches off, the network of Local Nodes can
act as an independent network, being the “in-the-room”
commands executed independently from the whole system.
Finally, the Room Boards are equipped with a Zigbee [4]
wireless interface for a remote control of the system
functionalities.
3. THE REALIZED BOARDS
The choice of hardware components for the board design
has been principally lead by the need of an easy, and low
cost, acquisition of the components from resellers, jointly
with a simple and effective PCB design. Mechanical
compatibility with cases of commercial light socket/switch
has been also considered. Fig. 2 shows four realized boards,
that are, respectively:
a) XN-CPU: the bridge between the Ethernet and the CAN,
able to manage all the room functions and to act as a
supervisor. Its core is a UBICOM IP2022 processor,
with 2 Ethernet interfaces and 1 CAN interface; a web
server is implemented, provided by UBICOM.
b) XN-3OUT: the digital output board, that manages up to
three relais over the CAN bus. Its core is a Microchip
PIC24F-16 bit.
c) XN-3IN: the input board that can manage up to three
analog and/or digital inputs over the CAN bus. Its core
is a Microchip PIC24F-16 bit.
d) XN-HOME + XN-XBEE: the ZigBee board with SPI
interface that can act as a brigde between the ZigBee
network and the CAN network. Its core is a Microchip
c)
CAN
d)
bus
 PIC24F-16 bit. the total bandwidth available on the uplink port of the layer
All the boards were designed, developed and tested at the 2 switch down to 10 Mbps. In this scenario we simulated
AUTOMA laboratories. different congestion conditions by means of an additional
“noise” traffic, generated through Iperf [8].
4. SYSTEM PERFORMANCE EVALUATION

Once defined the hardware of the system, it is necessary

to ensure the correct providing of all services. In order to
assess the system performance, we considered the case of a
home network based on a home server platform, able to
concentrate all the user’s services in a unique
hardware/software solution. To this aim, we adopted the
LinuxMCE client/server software platform [5], that allows
the management of all home entertainment and automation
services. LinuxMCE integrates a media and entertainment
system for music, movies, and TV, a home automation
system to control lighting and household appliances, a
phone system with video conferencing, a security system
with video surveillance and a home PC solution.
Fig. 3: Implementation of a QoS framework for HANs.
LinuxMCE, that relies on MythTV for the management
of digital television services [6], does not re-transmit
directly the received DVB-T transport stream. Instead,
digital television contents are first saved in local buffers, Quality of Service
thus allowing the implementation of a personal video
1) Measured Parameters
recorder (PVR) service, and then retransmitted on unicast
links. No real time protocols are adopted for retransmission;
The system model we are interested in relies on TCP
instead, TCP connections are used for point-to-point
instead of RTP protocol for audio/video streaming,
streaming. Differently from RTP, TCP implements
therefore we adopted a different approach to evaluate the
congestion control, so we want to verify the need and
Quality of Service. Differently from the previous case, no
effectiveness of QoS management also in this different
real time capabilities are implemented and, instead, TCP
scenario.
connections are exploited; therefore, QoS is mostly related
The implementation herein described for the QoS
to the allocated bandwidth.
framework is depicted in Fig. 3. As shown in the figure, we
A first set of measurements have been performed on the
considered the case of a unique home server, that exposes
ingoing traffic for the considered client. For the sake of
multiple services, and interfaces an Internet gateway that
brevity, we focus on the IP bandwidth allocated to the
ensures broadband data connectivity; multiple clients are
audio/video stream. Other measurements have been
located on the HAN. We focused on one of such clients, and
performed on the layer 2 switch uplink port, to evaluate its
analyzed its ingoing traffic through the Wireshark [7]
total allocated bandwidth, and the partial bandwidth
network traffic analysis software tool.
allocated to each service.
Hardware and Software Infrastructure
2) QoS Rules
The setup previously discussed relies on the adoption of
the following components:
Table I reports the QoS traffic classes and rules for the
1) QoS router: Pentium III 800 MHz with 256 MB RAM
considered system.
and Zeroshell Linux operating system.
We varied the guaranteed bandwidth allocated to the
2) Home server: Pentium IV 2.8 GHz with 512 RAM and
DVB-T service, in order to verify whether, in the case of
Linux operating system with LinuxMCE.
network congestion, such a traffic can be effectively served
3) Internet gateway: Intel Mobile 1.2 GHz with 512 RAM
by means of the QoS router.
and Windows XP operating system.
4) Clients: Pentium processors with at least 512 MB RAM
and suitable software clients.
In order to simulate a high number of clients, we reduced
 association with the QoS rules reported in Table I, we
TABLE I obtained results that confirm the effectiveness of the traffic
QOS RULES FOR THE SECOND IMPLEMENTATION. shaping function of the QoS router. They are shown in Fig.
Class Priority
Maximum Guaranteed 4. The priority assigned to the digital TV service, with
Bandwidth Bandwidth respect to the Internet service, reflects on its available
noise high variable variable bandwidth in different congestion conditions. The total
home guaranteed bandwidth is allocated to the different (3, in our
high 500 kbps 500 kbps
automation case) audio/video streams, in order to preserve their quality.
Internet In presence of congestion, however, a TCP connection may
low 1 Mbps 56 kbps be released, as occurs for the 6 Mbps guaranteed bandwidth
traffic
DVB-T curve in Fig. 4 (a), that exhibits a change in its slope. In
medium 7 Mbps variable such a case, the remaining connections can exploit
service
additional bandwidth, thus improving their quality. The
3) Test Results Internet service, on the contrary, has low priority, so its
allocated bandwidth is immediately reduced when
We have verified that, in absence of additional traffic, the congestion increases, with a substantial quality loss.
services we simulated (i.e. 3 audio/video streams for the
DVB-T service and a broadband Internet data stream) 5. CONCLUSIONS
require 8.2 Mbps total bandwidth, that is 82% of the
available bandwidth. Then, we have added a “noise” traffic In this paper we presented the so called XENO Project, a
with variable bitrate (namely 800, 1200, 1800 and 2300 complete solution for home and building automation,
kbps) in order to simulate different congestion conditions currently under development, and discussed the case study
(that can be due to other network services) and verify the of a home area network where a digital television service
effectiveness of the QoS rules set for the uplink port of the must be delivered in the presence of video surveillance,
layer 2 switch. automation, and Internet traffic. We described the most
important blocks of XENO, their main features, and verified
2.4 that the introduction of a Quality of Service router permits
to effectively regulate the priority and bandwidth assigned
Service BW [Mbps]

2.3
to each service, through the definition of proper QoS rules.
2.2
Therefore, the introduction of such an element in the home
2.1
3 Mbps network architecture should be recommended, in order to
2.0 5 Mbps avoid bottlenecks and ensure continuous availability of the
1.9 6 Mbps basic and essential home functional services.
7 Mbps
1.8
0.6 0.8 1.0 1.2 1.4 1.6 1.8 2.0 2.2 2.4 REFERENCES
Noise Traffic BW [Mbps]
(a)
[1] O. Martikainen, “Internet Revolution in Telecom,” in Proc.
1.2
IEEE JVA '06, Sofia, Bulgaria, Oct. 2006, pp. 58–62.
Service BW [Mbps]

1.0 [2] I. Han, H.-S. Park, Y.-K. Jeong and K.-R. Park, “An integrated
0.8 home server for communication, broadcast reception, and
home automation,” IEEE Transactions on Consumer
0.6
3 Mbps Electronics, vol. 52, pp. 104–109, Feb. 2006.
0.4 5 Mbps [3] C. Bae, J. Yoo, K. Kang, Y. Choe and J. Lee, “Home server
0.2 6 Mbps for home digital service environments,” IEEE Transactions on
7 Mbps Consumer Electronics, vol. 49, pp. 1129–1135, Nov. 2003.
0.0
0.6 0.8 1.0 1.2 1.4 1.6 1.8 2.0 2.2 2.4 [4] IEEE 802.15.4, “Wireless Medium Access Control (MAC) and
Noise Traffic BW [Mbps] Physical Layer (PHY) Specifications for Low-Rate Wireless
Personal Area Networks (LR-WPANs)”, IEEE, August 2003.
[5] http://linuxmce.com/
(b)
[6] http://www.mythtv.org/
Fig. 4: Measured bandwidth (Mbps) for the DVB-T service (a) and for the [7] http://www.wireshark.org/
Internet service (b), as a function of the noise traffic bandwidth, for several [8] http://dast.nlanr.net/Projects/Iperf/
values of the maximum guaranteed bandwidth for the DVB-T service.

In the presence of all the considered streams, in