Von Meier

Home Automation System Design And
Implementation Based On 6LoWPAN
YUXIN CHENG
2015.1
TRITA-ICT-EX-2015:7
2
Abstract
Home automation systems are collections of smart devices that enable vari-
ous functions within a house or building, such as light and plug control, energy
monitoring, temperature metering, air conditioning and heating, etc. Usually,
these devices are smart sensors, that are implemented with low power commu-
nication protocol like ZigBee and 6LoWPAN and only can be controlled from
an Internet gateway. Nowadays, there are lots of home automation products on
the market for customers. User can use application on smart phone to control
the products they bought. The control command can go through a cloud-based
server and be directed to the corresponding gateway, and finally reach to the
sensor devices, which is referred to as ”cloud-based mode” system.
However, this single mode is not efficient under some circumstances where the
Internet is not enabled or allowed. In this thesis work, a hybrid system archi-
tecture is proposed, implemented and evaluated, which include both stand-only
and cloud-based mode. It offers a quick connection when user’s smart phone
and the sensor gateway are in the same private network. The proposed double-
mode system architecture fits user’s need and provides high reliability.
3
4
Abstrakt
Hemautomationssystem är smarta enheter som möjliggör olika funktioner i ett

hus eller en byggnad, såsom kontroll av ljus och uttag, energiövervakning, tem-
peraturmätning, luftkonditionering och uppvärmning, etc. Dessa enheter är
vanligtvis smarta sensorer, implementerade med lågeffekt kommunikationspro-
tokoll som ZigBee och 6LoWPAN som endast kan styras via en Internet-gateway.
Numera finns det flera hemautomationprodukter på marknaden. Användaren
kan med sin smarta telefon styra sina produkter. Kommandot går via en
molnbaserad server och vidarebefordras till motsvarande gateway, kommandot
når slutligen till sensoranordningarna, även kallat ”molnbaserat läge”.
Detta ”molnbaserade läge” är inte effektiv under vissa omständigheter där in-
ternetanslutning ej är tillänglig. I detta avhandlingsarbete föreslås, genomförs
och utvärderas en hybrid systemarkitektur som inkluderar både stand-only
och molnbaserade läget. Detta erbjuder en snabb anslutning när användarens
smartphone och sensor gateway är pår samma privata nätverk. Den föreslagna
systemarkitekturen passar användarens behov och ger hög tillförlitlighet.
5
6
Acknowledgement
I would like thank my parents for their love and support to me. Also I would
like thank my supervisors at ABB Corporate Research Center, Dr. Zhibo Pang
and Morgan E. Johansson for their great help and patience. Then, I would like
to thank my supervisor and examiner Dr. Jiajia Chen, Assistant Professor at
Optical Networks Lab, School of Information and Communication Technology
(ICT) KTH for the guidance, supervision and valuable advice. This work is
partially supported by EIT-ICT Lab Project ”M2M and Xhaul”. Finally, my
sincere gratitude goes to all my friends, for their love and help to me.
7
8
Contents
1 Introduction 15
1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2 Research Questions and Challenges . . . . . . . . . . . . . . . . . 16
1.3 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2 The 6LoWPAN Protocol 17

2.1 Introduction to 6LoWPAN . . . . . . . . . . . . . . . . . . . . . 17
2.2 Features of 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.1 Headers in 6LoWPAN . . . . . . . . . . . . . . . . . . . . 17
2.3 6LoWPAN vs. ZigBee . . . . . . . . . . . . . . . . . . . . . . . . 18
3 Related Study on Home Automation System 20

3.1 Different Studies about Home Automation System . . . . . . . . 20
3.2 Requirements of Home Automation System . . . . . . . . . . . . 20
4 System Architecture Design 22

4.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2 Home Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3 Cloud Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.4 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5 System Implementation 25
5.1 Introduction to the System Implementation . . . . . . . . . . . . 25
5.2 Watteco 6LoWPAN Devices . . . . . . . . . . . . . . . . . . . . . 26
5.3 Raspberry Pi Home Gateway Application . . . . . . . . . . . . . 27
5.3.1 Raspberry Pi . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3.2 Home Gateway Application . . . . . . . . . . . . . . . . . 27
5.4 Amazon EC2 Cloud Server . . . . . . . . . . . . . . . . . . . . . 28
5.5 More about the System Implemtation . . . . . . . . . . . . . . . 30
5.5.1 Long Polling Scheme . . . . . . . . . . . . . . . . . . . . . 30
5.5.2 Latency Measurement and Retransmission . . . . . . . . . 30
6 Results and Analysis 32

6.1 Functional Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.2 Performance Tests . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.2.1 Introduction of Performance Tests . . . . . . . . . . . . . 33
6.2.2 Stand-alone Mode with Single Hop . . . . . . . . . . . . . 33
6.2.3 Stand-alone Mode with Multi-Hop . . . . . . . . . . . . . 36
6.2.4 Cloud Server Mode with Multi-Hop . . . . . . . . . . . . 40
7 Conclusions and Future Work 44
8 Appendix 48
9
List of Figures
1 6LoWPAN Header[1] . . . . . . . . . . . . . . . . . . . . . . . . . 18
2 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 System Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4 Hardware Devices in the System Implemtation . . . . . . . . . . 25
5 The Sample Web Interface on the Home Gateway . . . . . . . . . 28
6 CO2 PPM in an office . . . . . . . . . . . . . . . . . . . . . . . . 32
7 CO2 Detector RTT . . . . . . . . . . . . . . . . . . . . . . . . . . 34
8 Partial Data from CO2 Detector . . . . . . . . . . . . . . . . . . 35
9 Histogram of 3 Devices’ RTT . . . . . . . . . . . . . . . . . . . . 36
10 3 Hops 6LoWPAN Network in Office Corridor . . . . . . . . . . . 37
11 System Ping of the First Device . . . . . . . . . . . . . . . . . . . 38
12 System Ping of the Second Device . . . . . . . . . . . . . . . . . 39
13 System Ping of the Third Device . . . . . . . . . . . . . . . . . . 40
14 RTT of the First Hop Device in Cloud Server Mode . . . . . . . 41
15 RTT of the Second Hop Device in Cloud Server Mode . . . . . . 42
16 RTT of the Third Hop Device in Cloud Server Mode . . . . . . . 43
10
List of Tables
1 Statistics of the Application RTT of three Devices . . . . . . . . 35
2 Statistics of the System RTT of Three Hops 6LoWPAN Network 39
3 Statistics of the RTT of Three Hops 6LoWPAN Network in Cloud
Server Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
11
12
Acronym
6LoWPAN IPv6 and Low Power Wireless Premise Area Networks

HA Home Automation
IP Internet Protocol
IOT Internet of Things
AWS Amazon Web Service
EC2 Elastic Cloud 2
PPM Parts Per Million
RTT Round Trip Time
HTTP HyperText Transfer Protocol
DNS Domain Name System
TCP Transmission Control Protocol
UDP User Datagram Protocol
PDR Packet Delivery Rate
13
14
1 Introduction
1.1 Purpose
In a smart home automation system, various of smart sensor devices are con-
nected with different functionality for users. Ordinary customers can easily buy
tons of different home automation system product on the market today. Users
are able to control their devices from their smart phone or tablet, at or be away
from home. The smart home market is growing rapidly with the entry of num-
bers of company like Honeywell, Nest, ABB, etc.
Despite of different companies’ products, from the devices’ perspective, there

are several popular technologies competing for market share. The dominating
communication technologies for wireless smart sensors are ZigBee, 6LoWPAN.
On the contrary to the high data rate network for multimedia and Internet
application, ZigBee and 6LoWPAN both use the physical layer and medium ac-
cess control layer (MAC) of IEEE 802.15.4, which is designed for low data rate
network for power-limit sensors and devices. The ZigBee network layer and
6LoWPAN adaption layer provides different routing mechanism to relay and
transfer the packet. In [1], it is proved that 6LoWPAN is an ideal protocol to
realize a uniform addressing scheme for low data rate networks as well as high
data rate networks. In ZigBee IP Specification [2], the ZigBee Alliance provides
its open iPv6-based standard, and the 6LoWPAN protocol is also included in
ZigBee IP protocol stack.
From the system perspective, usually the company will provide a cloud-based
server in their home automation system products. Users can control their de-
vices from smart phone or tablet whenever and wherever. However, the commu-
nication to the cloud-based server is mandatory in this architecture. We believe
this is not suitable for the all possible scenario. For example, the Internet con-
nection can be down in a user home. In this architecture, user cannot control
his devices, even though he is at his own home. Another example could be that
in a big hotel where hundreds of smart plugs are implemented, a centralized
control of this smart devices can be done within the hotel’s internal network,
which the outside cloud-based server is not necessary.
What we design and implement is a double-mode system architecture, where

not only the cloud-server is provided, but stand-alone mode is allowed when the
user-end (smart phone, tablets, etc) and the smart devices are within the same
internal network. Users can choose their preference whether cloud-based sever
or stand-alone mode is suitable.
15
1.2 Research Questions and Challenges
The main goal of this thesis work is to design a demo of home automation
system based on the current third party devices from Watteco. The protocol
stack of the Watteco devices is studied in order to implement the application on
the home gateway. Meanwhile, enabling the cloud server mode requires certain
mechanism to penetrate the private network firewall. To evaluate the system
performance results, we separate into two categories: functional test where dif-
ferent functionalities of the devices are tested, and the performance tests, where
the round-trip time (RTT) from different test scenarios are collected and calcu-
lated. The RTT is an important parameter in system evaluation and the RTT
result will be influence by certain different variables. To build a successful sys-
tem where a desirable RTT is reached, these different variables that can change
the RTT need to be examined.
1.3 Structure
The structure of the remaining part of the report is as follows:
Chapter 2 gives a brief introduction to the protocol 6LoWPAN. First, the archi-
tecture of 6LoWPAN protocol is shown. Second, we introduce some important
features of 6LoWPAN. Third, we compare 6LoWPAN to another famous pro-
tocol in home automation field: ZigBee.
In chapter 3 we did the literature study of home automation system. Different

home automation systems are compared. We also conclude and propose the
requirements and some gaps in the current home automation system.
In chapter 4, we propose the two-mode hybrid architecture of home automa-

tion system. We separate the system into three different modules and these
three modules are shown and expained into details.
Chapter 5 gives the detailed implementation of the hybrid home automation

system demo. We explain the different technical mechanism in the Wattaco de-
vices, home gateway application as well as the application running on Amazon
EC2 cloud server.
In chapter 6 we shown the results collecting from different test scenarios. First,
we test the functionalities of the devices. Then, the single hop, multi hop RTT
of the devices in stand-alone mode. For the cloud server mode, we test the multi
hop case.
In chapter 7, we conclude the project work and the future work.
16
2 The 6LoWPAN Protocol
2.1 Introduction to 6LoWPAN
6LoWPAN is a protocol definition to enable IPv6 packets to be carried on top
of low power wireless networks, specifically IEEE 802.15.4.[3] Utilizing the In-
ternet Protocol (IP) in sensor network will bring us lots of advantages. First,
it simplifies the connectivity model. In the past, the gateway needs to be able
to translate between different application protocols of sensors and the standard
Internet Protocol. Second, using IP based protocols, users can employ different
tools that are already developed for configuring ,debugging networks. There
is no need to develop a brand new tool set to deal with different sensor pro-
tocols. Third, since all network protocol stack are IP based, there are existed
standards such as UDP, TCP, ICMP, DNS and existed services like load balanc-
ing, caching, firewall that are enable for network programmer and developers to
choose and use.
6LoWPAN is a developing standard from the Internet Engineering Task Force

(IETF) 6LoWPAN Working Group. The standard is designed to enable the
traditional IP running on the sensors. However, traditional IPv6 packets are
too expensive to the regular sensors. The IPv6 packet header is 40 bytes while
the MTU of 802.15.4 frame is 127 bytes.[4] Thus, a certain head compression
mechanism needs to be implemented.
2.2 Features of 6LoWPAN

2.2.1 Headers in 6LoWPAN
There are three types of headers in 6LoWPAN standard: the Dispatch Header,
the Mesh Header and the Fragmentation Header.
The Dispatch Header:
The dispatch header is 1 byte large and it is used to define the type of header
to follow. If the dispatch header starts with 00, it identify that it is a non-
6LoWPAN network. If it starts with 01, it is then a 6LoWPAN network. The
following 6 bit represent whether it is a IPv6 uncompressed header (000001) or
IPv6 HC1 compressed encoding (000010). 111111 is reserved for the future use.
The Mesh Header:
The mesh header indicates how to encode the hop limit and the link layer
source and destination of the packet. It includes two single bit fields to indicate
whether the address is a short or long address, since 802.15.4 standards allows
both 16 bit short addresses and standard 64 bit addresses. The next 4 bit field
is the hops left field, which indicates the number of the hops left in the route.
17
The Fragmentation Header:
If the packet size is larger than the size of the 802.15.4 frame (102 byte of
payload), the fragmentation and reassemble need to be supported. In the first
fragment header, the data size and the datagram tag, and the following fragment
header also includes the datagram offset. Although in most sensor network, the
application should be aware of the underlying link layer frame size limitation,
the fragmentation header is still supported in order to be compatible with stan-
dard IPv6 protocol.
Figure 1: 6LoWPAN Header[1]
2.3 6LoWPAN vs. ZigBee

ZigBee is one of the most popular low-cost, low-power wireless networking stan-
dard that is widely used in smart home,smart energy, etc. The ZigBee Alliance
holds the brand mark of ZigBee along with tons of ZigBee products. Same as
6LoWPAN, it also utilizes IEEE standard 802.15.4 standard. From the point of
interoperability, the ZigBee devices can interoperate with other ZigBee devices.
But in order to communicates with non-ZigBee network, the ZigBee devices
need an application layer gateway to translate different protocols. 6LoWPAN,
on the other hand, offers interoperability with other wireless 802.15.4 devices as
well as other IP networks. Only simple bridge or router devices are required.
[3][5][6][7] give more technical comparison of ZigBee and 6LoWPAN. It is shown
18
that in ZigBee network, the code size with mesh network can be as large as 32K
bytes to 64K bytes, while in 6LoWPAN network, the code size with mesh net-
work is 22K bytes.The RAM requirement to ZigBee is 8K, and for 6LoWPAN
only 4K is required. The header overhead of ZigBee is 8 to 16 bytes, while the
header of 6LoWPAN is 2 to 11 bytes. For the network size, 6LoWPAN support
26̂4 network size and ZigBee support up to 65K.
19
3 Related Study on Home Automation System
3.1 Different Studies about Home Automation System
Home automation system is a popular field in academic research. [8] provides
a home automation system where users can control ZigBee devices from their
mobile phones and tablets. The mobile devices can either control the ZigBee
devices directly, or with a USB dongle, or through the public Internet. [9] devel-
oped a Java based home automation system. All the home automation devices
are connected to an embedded board physically and a Java web sever is used
to provide remote access to the system. [10]proposed and implement a ZigBee
home automation system where a home gateway provides interoperability be-
tween the local ZigBee and Wi-Fi network work and the Internet. [11]proposed
a OSGI (Open Service Gateway Initiative), which home automation system for
administration and maintenance can be accessed from service provider.
These systems have made a great contribution to the development of home

automation system design. However, it is mentioned in the last chapter, all
home automation system based on ZigBee required a gateway or device coordi-
nator to translate the different protocol used in the sensor’s network and outside
internet network. 6LoWPAN is more configuring friendly compare to ZigBee.
There are studies on 6LoWPAN in home automation, too.
[12] provides a cloud-enabled home automation system based on UPnP over

IPv4/IPv6 and 6LoWPAN. The gateway supports the traditional IPv4 inter-
facing over WiFi or Ethernet. However, only cloud-based mode is supported
according to this paper. [13] gives a brief introduction of 6LoWPAN devices
design and the interactions between 6LoWPAN devices and home automation
system defined by users. This paper mainly focus on the downside 6LoWPAN
device design, but the system scope is not included.
3.2 Requirements of Home Automation System

In the home automation system design, there are certain technical requirements
like security, reliability, latency and power consumption that need to be taken
into consideration.
Security is always one of the most important issues in the system design. Con-
fidentiality, authentication and accessibility of the system, etc, there are tons of
features in the home automation system design. Confidentiality means that all
the user’s data, user’s sensor’s data should be well stored and no one else but
user can have the access to them. Authentication should be done in the control
of the devices, from the sensor gateway directly or from the cloud server indi-
rectly. The devices should be able to authenticated the controlling command.
Accessibility to the devices and to the cloud server are both important. Jam-
ming the wireless channel of the device and the denial of service to the cloud
20
server will lead to the inaccessibility to the home automation system.
Reliability of home automation device and home automation system is both

important. The reliability of the device is limited to the interferences and dis-
tortions of radio signals. In a commercial home automation system product,
there will be lots of users. Thus, a reliable cloud server platform is a key issue.
Choosing a good cloud platform along with relative service will simplify the
work a lot.
Latency is what user can experience directly. The latency in a home automa-
tion system is formed by the processing time on devices, home gateway, cloud
server, as well as the signal transmission time. The bandwidth of the channel
that devices are using will limit the latency. The retransmission mechanism
between device and gateway or the gateway between the cloud server will make
the total latency of one user behavior differ a lot.
Power Consumption needs to be taken into consideration, especially for those

wireless devices in the sensor network. The battery life is a strict parameter of
the wireless devices. A good battery life will in turn increase the reliability and
the latency of the system. The low power device might increase the transmission
time, causing packet loss or even lose the connection to the gateway.
21
4 System Architecture Design
4.1 System Architecture
In this section, the conceptual design of a double-mode home automation system
is described. The system is outlined in Fig 2. The system is basically formed
of three modules: the Home Gateway Module, the Cloud Sever Module, and
the User node Module. The user can connect to cloud-base server or the home
gateway directly from their smart phone or tablet, depending on user’s choice
and the network connection.
Figure 2: System Architecture
4.2 Home Gateway

The Home Gateway Module contains four sub-modules: cloud-sever commu-
nication module, local communication module, control model and a database.
The sub-module’s explanations are described below:
Cloud-Sever Communication Module: This module is used to receive the

operation command from the cloud server side and transmit the required data
to the cloud sever. This module also maintain the long pulling connection to
the sever, so that regular firewall policy will not be violated. A PING-PONG
scheme is used to report the alive status of the home gateway to the cloud sever,
combined with the regular data report from the down layer sensor devices.
22
Local Communication Module: This module allows the connection between
the home gateway and user end node when they are in the same private net-
work. This module runs a daemon thread to answer any gateways’ existence
check request from the user end node within the same private network. This
module also runs a simple web interface to allow the direct operation on this
gateway, as long as the credential and authentication information is provided
correctly.
Control Module: This module is used control the smart sensors. It receives
the data and event from every sensor in the network, and transmit the operation
command for cloud sever module and local communication model.
Database: Every home gateway runs a local database. It stores the creden-
tial and authentication information, and MAC address, current status of all the
sensors in this network and all the required data history from user.
4.3 Cloud Server

The Cloud Server Module contains four sub-modules: user communication mod-
ule, gateway communication module, main module and a database. The sub-
module?s explanations are described below:
User Communication Module: This module receives the request from user
node and respond the request data to user. It uses our self-defined interfaces
for the connection from the mobile application on user node.
Gateway Communication Module: This module is used for the connec-

tion between the home gateway and the cloud server. Since it is highly possible
that the home gateway is behind a firewall and it is not possible to initial the
connection from the server side, the long polling scheme is used the hold up the
connection. Also a PING-PONG scheme is used to report the aliveness of the
home gateway.
Main Module: This is main logic module of the program on the cloud server.
It combines the user communication module and gateway communication mod-
ule together, and directs the right IP address from the database.
Database: This module contains user’s information, such as the IP of user’s

home gateway. After getting user’s permission, it also contains the data of every
sensor and history record, since the memory and storage on the home gateway
is limited.
4.4 User Interface

A user node module could be user’s smart phone, tablet, laptop. We provides
a simple user interfaces application. From user’s side, there are three possible
23
scenarios, described as follows:
The user node and the home gateway is not in the same private network. Under
this situation, the user node needs to connect to the cloud server by the appli-
cation on the mobile devices.
The user node and the home gateway are in a regular private network. The
application on user’s mobile devices will scan the current private network, try
to build the connection to the local communication model on the home gate-
way. The home gateway daemon thread will listen and respond the request from
the user node. It is worthwhile to point out that user can also choose to con-
nect to the cloud server under this situation. The choice is left to user to decide.
There is another special case, where even though the user node and the home
gateway are in the same private network, the scanning step in the last scenario
is not permitted due to the firewall policy reason. This is quite possible in a
company’s or factory’s private network. Under this situation, the administra-
tion is needed to check the home gateway’s IP first. Then it is still possible to
control the gateway and the sensors remotely by the web interfaces on the home
gateway.
Figure 3: System Modules
24
5 System Implementation
5.1 Introduction to the System Implementation
In this chapter, the demo system implementation is introduced based on the
system modules in the last chapter. We have 6LoWPAN-supported smart home
devices from Watteco, including two smart plugs and one CO2 detector, as well
as a 6LoWPAN border router. We used a Raspberry Pi with a Raspbian image
as the home gateway. A cloud server is put on Amazon AWS EC2 platform.
This section provides a thorough discussion of the system implementation.
Figure 4: Hardware Devices in the System Implemtation
25
5.2 Watteco 6LoWPAN Devices
For our two-mode system architecture home automation system implementa-
tion, we use 6LoWPAN devices from Watteco company. Two smart plugs and
one CO2 detector are used in our implementation. All the devices are wireless
and communicate using Radio Frequency (RF) at 868MHz (ISM band). The de-
vices implement recent IETF networking 6LoWPAN standards for compressed
IPv6 networking over low power networks (RFC4944, RFC6282, RFC 6775),
IPv6 routing protocol for Low-Power and lossy network (RPL) for mesh net-
working (RFC6206, RFC6550).
The application layer of Watteco devices leverages the ZigBee Cluster Library
(ZCL) format. Watteco provides a documents with the corresponding ZCL de-
scription, which allows us to code our program to control and communicate to
the devices. More information of the application of the Wattaco devices can be
found in their User Guid.[14]
Besides the 6LoWPAN smart devices, a USBStickRF-BorderRouter is provided

from Watteco. It can be plugged on a Linux host and creates the link between
standard IPv6 applications and 6LoWPAN devices. It is also in a role to open
the sensor network, which in turn to allow the new devices joining in.
There are three devices used in the home automation system: two smart plug
and a CO2 sensor:
Smart Plug:
In the application layer of the smart plug, two main cluster is included besides
the basic cluster: On/Off Cluster and Simple Metering Cluster. The On/Off
cluster allows the control and management to turn on or off the current smart
plug, or simple reverse the on/off state. The simple metering cluster is supposed
to allow the metering the summation of the active energy and the active power.
However, after the experiment, we believe the simple metering cluster in Wat-
taco smart plug is incorrectly implemented. The data retrieved from the smart
plug is simple incorrect. The on/off cluster, on the other hand, is correctly
implemented.
CO2 Detector:
The CO2 Detector implements the Analog Input Cluster besides the basic clus-
ter. The data format in the frame payload is single-precision floating point.
Thus, some format transform needs to be done in the gateway application to
provide a decimal representation, given a better user experience.
The CO2 detector allows to measure the IAQ (Indoor Air Quality) in a room.
It can be used to determine the presence of a person in a room (the increase
in CO2 measurement.) The device has a narrow carbon dioxide concentration
26
measurement range (in ppm) from 0 to 5000 ppm. [14]
All these three devices have their own MAC address and can be configured in
to relative IPv6 address based on the configuration of the boarder router. More
information for the configuration the 6LoWPAN network is shown in chapter 7.
5.3 Raspberry Pi Home Gateway Application

5.3.1 Raspberry Pi
It is worthwhile to introduce the Raspberry Pi we used as the home gateway.
The product we chose to use is the Model B of Raspberry Pi. It has 512 MB of
RAM, two USB ports and a 100Mb Ethernet port. We use the Raspbian Image
as the gateway operating system. Raspbian is a Linux operating system based
on Debian distribution optimized for the Raspberry Pi.
5.3.2 Home Gateway Application

The home gateway application is a python-based program running on the Rasp-
berry Pi home gateway. But before jumping into details of the application, there
are server different IP address need to be clear for the readers. In the Raspberry
Pi home gateway application, there is an IPv6 address and an IPv4 address. The
home gateway application is running as a server to the 6LoWPAN devices, and
as a client to the cloud server in the home automation system. Thus, the IPv6
address is used to communicates to the 6LoWPAN devices while the IPv4 ad-
dress is used to communicates to the cloud server as well as working as a web
engine for the local HTTP request. Python doesn’t support IPv6 socket well,
so the Control Module is written in C. In the control module, it is possible to
send and receive IPv6 packets from and to the 6LoWPAN devices. The data is
saved in a database, which in this case is just a simple TXT file for the simplify
the analysis the result.
The local communication module is an IPv4 socket listening on the port 80.
In the web interface we provide, user is able to identify the states of all three
devices, such as the IPv6 address, current network connection state, current
average latency as well as the control to the devices such as turn on/off a
smart plug, get the current measurement of the CO2 devices. When there is
a ’GET’ HTTP request received, the home gateway application will reply the
webpage with the current status. When there is a ’POST’ HTTP request re-
ceived, the home gateway will ask the control module to do the requested work
(e.g. ’switch1=on’). Meanwhile, the current status will be replied.
27
Figure 5: The Sample Web Interface on the Home Gateway
5.4 Amazon EC2 Cloud Server

Our cloud server program is running on Amazon AWS EC2 platform. In order
to save the cost, the type is t2.micro, which contains one virtual CPU, 1 GiB
memory and 8 GB on storage is chosen as the running server instance. The
cloud server application is also written in python. It listens to the port 80 of its
public IP, and 8080 as the port communicating to the home gateway. In this
thesis work, only minimum work is done at the server part. When an HTTP
request (GET, POST) is received at the cloud server, it forwards it to the home
gateway on the port 8080. When it receives the reply from the home gateway,
it will forward back to the original request.
In the future, more work can be done in the cloud server module. For now,
it is just a remoter server. But the real cloud server is more than just a re-
mote server. First more features can be added. For example, show the real
time measurement graph to the user, or multi home gateway supported. In this
work, only one home gateway is supported, due to the reason of lack enough
devices. Second, the real cloud services provide by AWS can be used in the
home automation system. The AWS EC2 provides many easy-to-use services
to their costumer, such as load balancing, auto scaling up/down, etc. The use
of cloud service in home automation is beyond this thesis work, but can be
done in the future. In this work, the cloud server application simply works as
a proxy, between the user and the home automation gateway, when the user
devices (cellphone, laptop, etc) is not in the same private network as the home
28
automation gateway.
29
5.5 More about the System Implemtation
5.5.1 Long Polling Scheme
When the home gateway application is started at the beginning, it will initial
a request to the cloud server. This is due to the reason that most gateway is
in a private network, it is impossible for a cloud server with a public IP other
than the private network IP to initial the connection. After the connection is
built, the home gateway will send an IP packet with payload of ’PING’ to the
server every 3-5min and the server will reply a ’PONG’ message in the same
way. The is so-called ”PING PONG” mechanism, and it not only shows the
aliveness of home gateway and the cloud server to each other, but keep the
socket alive as well. In some firewall configuration, the socket alive time is lim-
ited due to the system configuration and private network firewall policy, and the
socket will be closed after certain idle time. The long polling scheme keeps the
socket open, and also let both server and client know that the other part is alive.
5.5.2 Latency Measurement and Retransmission

As it is shown in the web interface, there is the average latency of each de-
vice. The average latency shown here is the latency between the home gateway
and the devices. There are thread that keep pinging each devices every ten
seconds. The home gateway application will refresh the average latency based
on the system ping ICMP reply. If any device lost the connection, the connec-
tion state will be False, and the average latency will be erased and starts from 0.
In the chapter 6, it is shown that the packet maybe lost in the 6LoWPAN
networks. However, there is no retransmission mechanism in this home au-
tomation system. It is due to the reason that the retransmission should be done
in the devices application layer, not from the system perspective. The packet
loss in 6LoWPAN network can be described as two following reasons: channel
interference and the Watteco devices are unstable. The Watteco devices are
unstable in the experiment, and sometimes need to be reboot to reconnected
to the network. And there is no retransmission mechanism shown in their ap-
plication layer stack. There might be retransmission done in the network layer
of the devices, but the programmer using Watteco devices are unable to aware
the state of the connection. It is better to shown in the application layer of the
device whether it is waiting the response or their is packet loss happening. For
now, some commands don’t have any reply at all, such as turn on/off a device.
It is possible to do the retransmission in system design. For example, retrans-
mit the request if there is no reply in certain time. However, this will increase
the reaction time of the whole system and lead to a bad user experience. Since
all the connection in the system is TCP connection except the 6LoWPAN net-
works, which is UDP packets sending, there is no way for the other part causing
the packet loss. Thus, the improvement of the 6LoWPAN devices is required
to improve the reaction time and the user experience. More system round trip
30
time (RTT) result and analysis can be found in the next chapter.
31
6 Results and Analysis
6.1 Functional Tests
The functional tests cover all the functionalities experiment of Wattaco devices.
According to the device manual, the CO2 detector is able to show the current
CO2 ppm (parts per million) from its analog input cluster (0x00C) and the
smart plug is able to be switched on or off from its on/off cluster (0x0402) and
show the metering of active energy and reactive power from its simple metering
cluster (0x0052).
Figure 6 shows the data collected from the CO2 detector in an office on a
Figure 6: CO2 PPM in an office
random working day. From the graph, it is obvious that since the day began,
the CO2 ppm value increased from 400+ ppm to 600-700 ppm, due to the in-
crease of the number of people in the room leading to the increase of CO2 ppm.
From 12 O’clock, people were out for lunch, so the CO2 ppm decreased until
people were back for work in the afternoon. The CO2 detector functionality
works well. However, it is worthwhile to point out that the CO2 detector is not
working stable. Sometimes it may lost connection, so the reboot is needed. The
32
way of reboot the device and rejoin the network will be on next chapter.
For the functionality tests on the two smart plug, a short video is made and put
on
https://www.youtube.com/watch?v=PcpE1cdhJwAlist=UU7O9NrTfCIhyXeKXOI8XbZg.
The on/off cluster works fine but the simple metering cluster does not work.
6.2 Performance Tests

6.2.1 Introduction of Performance Tests
The feasibility of the home automation system can be determined by calculating
the round trip time (RTT), packet loss and power consumption. It is impossible
to measure the power consumption using Wattaco devices, so the performance
tests are mainly focused on RTT and packet loss. In general telecommunication
definition, RTT is the time length between a signal is sent and the acknowl-
edgement of this signal is received. In computer system, this signal is the IP
package. For the RTT measurement, it is shown in chapter 2 that since the
devices are implement 6LoWPAN protocol stack and are IP based, it is possible
to used the regular network tools. We used system ICMP Ping command to
show the system ping RTT, as well as setting timer when send a read value
command to sensor in the system scripts to show the application ping RTT.
Both system ICMP command and the application Read command are sent si-
multaneously. For the network topology, since 6LoWPAN support multi hop
links, both single hop 6LoWPAN network and multi-hop 6LoWPAN network
RTT are tested in stand-alone mode. For the cloud server mode, only RTT of
multi-hop 6LoWPAN network topology are tested.
6.2.2 Stand-alone Mode with Single Hop

In this stand-along Mode with single hop test, the demo is the same with figure
4, except that the cloud server is not included. All three devices are connected
to the gateway directly. In this experiment, both system ICMP ping command
and the application timer setting are used to calculate RTT. The application
RTT timer starts from the read value command sending from the gateway and
stops when the reply from the sensor is received and processed by the gateway
application. In figure 7, the values collected from CO2 detector are shown with
the number of the test run in x axis and the round trip time in millisecond in y
axis. The tests are run every second.
33
Figure 7: CO2 Detector RTT
From figure 7, it is obvious that both system ping RTT and application
ping RTT have the same pattern, i.e. when ping command RTT is larger, the
application RTT is larger. This suggests that the packet transmission time is
the majority in RTT rather than the home automation system execution and
processing time. Figure 8 gives more clear details on the same patten. It is the
part of data shown in figure 7.
34
Figure 8: Partial Data from CO2 Detector
The plot of system ping RTT and application ping RTT of the two smart
plug have the same patten shown in figure 7 and figure 8. To save the space, only
final histogram of RTTs collected from these 3 devices are shown here in figure 9.
From the statistic perspective, all three devices (CO2 detector, smart plug1,
smart plug 2)have a similar average application ping RTT (207.6ms, 206.9ms,
207.0ms). We also calculate the standard deviation of each device (39ms,
39.5ms, 40.6ms). If we set the bound of maximum acceptable RTT as (av-
erage RTT + 1* standard deviation), about 88% of the RTT response can meet
the requirement. This is demoted as PDR (packet delivery rate). Similarly,
about 95% and 97% percent of response can be received within (average RTT
+ 2* standard deviation) and (average RTT + 3* standard deviation).
Table 1: Statistics of the Application RTT of three Devices

CO2 Detector Smart Plug1 Smart Plug2
Min RTT(ms) 175.0 174.0 174.0
Average RTT(ms) 207.6 206.9 207.0
Max RTT(ms) 622.0 650.0 635.0
Sigma: Standard Deviation(ms) 39.0 39.5 40.6
Packet Delivery Rate of (average RTT+1*Sigma): 87.12% 88.11% 88.78%
Packet Delivery Rate of (average RTT+2*Sigma) 94.52% 94.77% 94.98%
35
Figure 9: Histogram of 3 Devices’ RTT
6.2.3 Stand-alone Mode with Multi-Hop

The Wattaco 6LoWPAN devices support multi-hop link in the network. This
means that it is possible that the device can be far away from the border router,
as long as there are other intermediate devices helping forward and relay the
packet. In our experiment, a three-hop 6LoWPAN network is built. We put all
three devices in a long corridor and according to the routing table on the border
router, three devices are working as the three hops network well.
36
Figure 10: 3 Hops 6LoWPAN Network in Office Corridor
Similar to the last subchapter, we also collected RTT as the system perfor-
mance parameter. However, in this multi hop 6LoWPAN network, we only test
the system ping RTT. The system ICMP ping command can tell us the RTT,
as well as the packet loss happening if it happens. In the 3 hops 6LoWPAN net-
work, packet loss happens in the packet transmission to the second hop device
and the third hop device. More statistics can be found in table 2.
37
Figure 11: System Ping of the First Device
38
Figure 12: System Ping of the Second Device
Figure 11-13 shows the system ping RTT of all three devices. It is obvious
that the longer distance between the device and the gateway, the longer RTT it
takes. For the first, second and third device, the average system RTT is about
184ms, 324ms and 465ms. Similar to the last subchapter, we also calculate the
standard deviation, as well as the packet delivery rate at (average RTT + 1/2/3
* standard deviation). The above statistic along with the packet loss are shown
in table 2.
Table 2: Statistics of the System RTT of Three Hops 6LoWPAN Network

First Hop Second Hop Third Hop
Min RTT(ms) 154.0 258.0 364.0
Average RTT(ms) 184.1 324.5 465.3
Max RTT(ms) 846.0 1531.0 1950.0
Sigma: Standard Deviation(ms) 47.0 96.9 101.0
Packet Loss 0% 3.15% 4.32%
39
Figure 13: System Ping of the Third Device
6.2.4 Cloud Server Mode with Multi-Hop

In this subsection, we will show the results collected in cloud server mode with
multi hop 6LoWPAN devices. The total RTT is calculated from the moment
when user sends the requesting command from user’s laptop, to the moment
when user get the result on laptop. The request will first forward to the Amazon
AWS server, and the Amazon server will forward to the home gateway. The
gateway will then send the relative command to the devices in the 6LoWPAN
network. The response will forward to user’s laptop all way back.
40
Figure 14: RTT of the First Hop Device in Cloud Server Mode
41
Figure 15: RTT of the Second Hop Device in Cloud Server Mode
Figure 14-16 shows the result. It is obvious that the response time is larger
than 2 second. There are multiple reason for that. Firstly, the distance between
the user laptop to the cloud server and the distance between the cloud sever
to the home gateway is one main reason that enlarges the RTT. However, the
server is put on Ireland region, the total RTT from Sweden to Ireland is about
50ms. Second, the network service provided by the internet service provider
might be unstable. Third, the service provide by Amazon might be limited,
since for the cost saving, only the minimal server is chosen, and the bandwidth
and CPU processing ability are limited during in large traffic. More statistics
can be found in table 3.
Table 3: Statistics of the RTT of Three Hops 6LoWPAN Network in Cloud

Server Mode
First Hop Second Hop Third Hop
Min RTT(s) 2.247 2.354 2.463
Average RTT(s) 2.3471 2.4736 2.6124
Max RTT(s) 4.307 3.8499 4.0616
Sigma: Standard Deviation(s) 0.0943 0.1187 0.1232
42
Figure 16: RTT of the Third Hop Device in Cloud Server Mode
43
7 Conclusions and Future Work
In this project, a simple demo of home automation system based on the Wat-
taco 6LoWPAN devices are design and implemented. Both stand-alone mode
and cloud server mode is supported. The result is not good enough, since the
round trip time can be as high as 2 second in cloud server mode and 0.2-0.5
second in stand-alone mode. The reason of these unsatisfying result might be
the problem on Wattaco devices and the low cost server.
However, from the protocol perspective, 6LoWPAN is still a quite promising

standard in home automation. The regular user might not be able to feel the
difference between a 6LoWPAN device and a ZigBee device, but for the system
administrator and the software programer, 6LoWPAN simplifies the work since
there are tons on existed tools can be used.
In the future, new 6LoWPAN device along with the device’s application protocol
stack will be design to provide more stability. It will be easier to integrated the
device into the system with own protocol stack and improve the performance.
Meanwhile, more work on cloud server in home automation can be studied.
This project work only use the cloud server as a remote server. There are other
features of the cloud server can be studied and used in home automation system
design and implement.
44
45
References
[1] Gross Tobias Kays Rudiger Schaefer, Falk-Moritz. Energy consumption
of 6lowpan and zigbee in home automation network. IFIP Wireless Days,
(1-3), 2013.
[2] Zigbee ip specification. http://www.zigbee.org/Specifications/ZigBeeIP/Overview.aspx.
[3] Geoff Mulligan. The 6lowpan architecture. Embedded networked sensors:
Proceedings of the 4th workshop, (EmNets ’07), (78-82), 2007.
[4] Carsten Borman Zach Shelby. 6LoWPAN: The Wireless Embedded Internet
(Wiley Series on Communications Networking and Distributed Systems).
2010.
[5] Hui J Culler, D. 6LoWPAN Tutorial,Tiny OS Technology Exchange. 2007.
[6] Kerkorian R. Cohen D. Gershenfeld, N. The Internet of Things, Scientific
American. 2004.
[7] Hui j Culler D Montenegro, G. Kushalnagar N. Transmission of IPv6
Packets over IEEE 802.15.4 Networks.
[8] Oprina George-Daniel Tapus Nicolae Zeisberg Sven Olteanu, Alexandru-
Corneliu. Enabling mobile devices for home automation using zigbee. 19th
International Conference on Control Systems and Computer Science, (189-
195), 2013.
[9] A. R. Al-Ali and M. Al-Rousan. Java-based home automation system.
IEEE Transactions on Consumer Electronics, 50(498-504), 2004.
[10] Fang Yao Xin Lu Khusvinder Gill, Shuang-Hua Yang. A zigbee-based
home automation system. IEEE Transactions on Consumer Electronics,
(422-430), 2009.
[11] S. Ok and H. Park. Implementation of initial provisioning function for
home gateway based on open service gateway initiative platform. The 8th
International Conference on Advanced Communication Technology, (1517-
1520), 2006.
[12] Novi Sad Serbia ; Mrazovac B. ; Teslic N. ; Papp I. Bjelica, M.Z. ; RT-
RK Comput. Based Syst. Cloud-enabled home automation gateway with
the support for upnp over ipv4/ipv6 and 6lowpan. Consumer Electronics
(ICCE), 2012 IEEE International Conference, (520-521), 2012.
[13] Jafar Saniie Thomas Gonnot. User defined interactions between devices on
a 6lowpan network for home automation. Technology Management Confer-
ence (ITMC), 2014 IEEE International, (1-4), 2014.
[14] Wattaco. IP Wireless Sensors User Guide, Specifications and Performance,
Control and Management Interfaces.
46
47
8 Appendix
48
Preliminary Study on Wireless Home Automation
Systems with Both Cloud-Based Mode and Stand-
Alone Mode
Zhibo Pang1, Yuxin Cheng2, Morgan E. Johansson1, Gargi Bag1
1, Corporate Research, ABB AB, Västerås, Sweden
2, ICT School, Royal Institute of Technology (KTH), Stockholm, Sweden
{pang.zhibo|morgan.e.johansson|gargi.bag}@se.abb.com, yuxinc@kth.se
Abstract—As the Smart Home segment is an intersection of communication architecture is also required to support both
numerous industries including consumer electronics, telecom, Cloud-Based Mode and Stand-Alone Mode.
internet, and building automation, a Home Automation (HA)
system requires flexible wireless communication architecture to In particular, in the Cloud-Based Mode, the WSAN devices
not only take the advantages of wireless technologies such as of the WiHA system are all connected to a kind of server in the
reduced cost of installation and maintenance and improved user cloud and users can monitor and control the devices through
experiences but also fulfill the concerns of various industrial the internet during configuration as well as usage. In the Stand-
stakeholders. From this point-of-view, neither the pure Cloud- Alone Mode, the devices are interconnected to each other
Based nor the Stand-Alone architecture is sufficient. In this directly or through a kind of local gateway, and users can
paper, an IP-based hybrid architecture is presented which can monitor and control the devices locally without any
support flexible combination of Could-Based Mode and Stand- involvement of internet or cloud server. The Cloud-Based
Alone Mode. Preliminary prototyping based on the 6LoWPAN Mode can reduce the effort for end consumer to install,
and experimental evaluation of performances have indicated the configure and manage the WiHA devices since all these work
technical feasibility as well as future directions of improvement. are done either by the device manufacture if the cloud services
are also included in the product package, or by the a dedicated
Keywords—Internet-of-Things (IoT); Wireless Sensor and service provider. It is usually preferred in the do-it-yourself
Actuator Networks (WSAN); 6LoWPAN; Cloud-Based Mode,
(DIY) market driven by new entrains from out of HA industry
Stand-Alone Mode; Home Automation (HA)
like the Google Nest[10] and Apple HomeKit [11] and telecom
or broadcast service providers. However it is not sufficiently
I. INTRODUCTION friendly to the system integrators and installers which play
As digital representation of real world, the Internet-of- essential roles in the value chain of HA industry. Moreover, the
Things (IoT) integrates all kinds of sensing, control, security and privacy concerns from end consumers are also
identification, communication, networking, and informatics important challenge faced by the suppliers. In contrast to the
devices and systems, and seamlessly connects all the people Cloud-Based Mode, the Stand-Alone Mode gets rid of the
and things upon interests, so that anybody, at any time and any dependency of internet and cloud services. By doing this with
place, through any device and media, can more efficiently proper cyber security techniques, the issues about security and
access the information of any object and any service [1]. The privacy can be significantly reduced. As an expense, the
Home Automation (HA) is one of the most promising installation and configuration of WiHA devices are more
application area of the IoT. Thanks to the reduced cost of complicated for end consumers compared to usual consumer
installation and maintenance and improved user experiences, electronic devices and the WiHA devices in Cloud-Based
Wireless Sensor and Actuator Network (WSAN) technologies Mode. In practice, the installation and configuration work is
are being actively applied or developed [2]. Some of these usually done by professionals of system integrator or installers.
technologies that have gained much attention include the Therefore the Stand-Alone Mode is looked as friendlier to
ZigBee Pro [3], ZigBee IP [3], IETF 6LoWPAN (IPv6 over system integrators and installers since they can keep their
Low power Wireless Personal Area Networks) [4], EnOcean essential roles in the value chain, and it is usually preferred by
[5], KNX-RF[6], DECT ULE [7], Low Power WiFi [8], the established HA system suppliers which have rooted deeply
Bluetooth Low Energy [9], and Thread [10]. The designers of in the HA value chain [12].
Wireless Home Automation (WiHA) systems have to manage Given the pros and cons of the Cloud-Based Mode and
the challenges caused by the diverse requirements from Stand-Alone Mode, the HA industry is demanding a hybrid
different stakeholders in the value chain because the Smart architecture which can take the advantages of the both modes
Home segment is an intersection of numerous industries i.e. to simplify the system configuration and maintenance by
including consumer electronics, telecom, internet, and building the Cloud-Based Mode, to reduce the security and privacy
automation. In addition to the technical challenges about issues by the Stand-Alone Mode, and to make the solution
reliability, power consumption, and low complexity, the more friendly to both system integrators, installers, and
dedicated service providers by offering flexible combination of III. SYSTEM ARCHITECTURE
the two modes. However, the existing research on this is
insufficient from the point-of-view of HA industry (see section A. Overview
II). The proposed hybrid WiHA communication architecture
In this paper, an IP-based hybrid architecture for WiHA that can operate both in Cloud-Based Mode and in Stand-
systems which can seamlessly integrate both the Cloud-Based Alone Mode is illustrated in Fig. 1. The key elements of the
Mode and Stand-Alone Mode with minimized cost to switch Smart Home system including the WiHA system are separated
between the two modes. A prototype is implemented based on into three domains as follows.
the 6LoWPAN which brings native IP compatibility to low  HA Device Domain: It comprises all the field devices of
power and low cost wireless WiHA devices. A scalable the WiHA system including the sensors and actuators,
gateway architecture which can be deployed both on low cost WSAN network devices (e.g. routers, bridges), home
embedded devices in the homes or on high performance servers automation gateway, and Consumer User Interface (UI)
in the cloud is designed. A prototype system is implemented (e.g. smart phone with apps). The devices in the HA
and experimental tests are carried out with a focus on the Device Domain are connected by short range wireless
timing performances. The preliminary results have confirmed communications through the WSAN. In this domain, end
the technical feasibility of the proposed architecture but the consumers can interact with the WiHA directly through
round trip time, typically 207ms for 1 hop WSAN, is still too the sensors and actuators or through the Consumer UI,
long compared with the practical HA system requirements. which is called the Stand-Alone Mode.
This will be an important direction of future research.
 HA Service Domain: It comprises the backbone system of
The rest of the paper is organized as follows: in Section II the HA System Integrator, private cloud infrastructure, and
related works are reviewed from system architecture Installer UI (e.g. smart phone with apps). The HA Service
perspective. In Section III the proposed hybrid system Domain is interconnected by private cloud which is
architecture is introduced. The design of a minimal system and intensively safeguarded by firewalls. In this domain,
implementation of a prototype are presented in Section IV. In installers can interact with the WiHA devices in field
Section V, preliminary experimental results with respect to the through the Installer UI.
response time are given. Finally the paper is concluded in
Section VI.  IT Service Domain: It comprises the backbone system of
various IT services (e.g. energy analytics, home service,
II. RELATED WORK utility billing, and entertainment), public cloud
infrastructure, in-home IT gateway, and Consumer UI.
There exist a significant research work done with respect The IT Service Domain is interconnected by public cloud
the communication architecture of WiHA systems [13]. For through wired or wireless wide area network technologies
example, Olteanu et al. provided a home automation system such as 3G/4G, FTTH, Ethernet, HomePlug, etc. In this
where users can control ZigBee devices from their mobile domain, end consumers can only interact with the WiHA
phones and tablets [14]. The mobile devices can either control indirectly through the cloud, which is called the Cloud-
the ZigBee devices directly, or with a USB dongle, or through Based Mode.
the public Internet. Al-Ali and Al-Rousan developed a Java
based home automation system [15]. All the home automation
B. Domain-Based Access Control
devices are connected to an embedded board physically and a
Java web server is used to provide remote access to the system. In the proposed architecture, different domain has different
Gill et al. proposed and implemented a ZigBee home level of vulnerability. In the IT Service Domain which is the
automation system where a home gateway provides most vulnerable domain of the WiHA system, hackers can
interoperability between the local ZigBee and Wi-Fi network attack the WiHA system remotely from any place of the world
work and the Internet [16]. Ok and Park proposed a OSGI in theory. So the it has to be isolated as much as possible and
(Open Service Gateway Initiative), which home automation no direct control flow is allowed from the IT Service Domain
system for administration and maintenance can be accessed and the HA Device Domain.
from service provider [17]. These systems have made a great
contribution to the development of home automation system C. Domain-Based Network Integration
design. However, the authors have observed a gap between The classification of domains makes it convenient to decide
industrial practice and academic work. First, the architecture the networking technologies of each domain and in between
prosed in the literatures is lack of harmonization of Cloud- two domains. In the HA Device Domain, to increase the cost of
Based Mode and Stand-Alone Mode, i.e. they either focus on direct invasion to the sensors of actuators, short range wireless
Cloud-Based Mode or focus on Stand-Alone Mode. How to communication technologies with sufficient end-to-end
combine the two modes in a single solution is not presented. security is needed for the Home WSAN. Some of the
Second, the concerns of the HA system integrators and promising candidates are ZigBee Home Automation, ZigBee
installers are not considered sufficiently which implies the IP, and IETF IoT Stack (6LoWPAN, RPL, and CoAP). In the
need of re-thinking this question from the point-of-view of HA Service Domain and IT Service Domain, conventional
industrial value chains. internet technologies can be used but they should fulfill the
requirements of private cloud and public cloud respectively.
HA Service Domain IT Service Domain
architecture helps to balance the control and distribution of
HA System
benefits through the value chain. For example, an energy
Integrator IT Services efficiency company can provide energy analytic service by
collecting the power consumption pattern, plan of activities,
and real-time price of utilities and heat, and reduce the energy
cost by optimizing the schedule of loads. To do this, the energy
Public Cloud
analytic service provider should get the authentication from the
End
Consumer UI Consumer
HA System Integrator and install it into the Home IT Gateway
Home IT accordingly. Otherwise, it is not allowed to control the field
Private
Gateway devices even though it might be able to read the load data from
Cloud the field.
IV. DESING OF A MINIMAL SYSTEM

HA Device
Home Automation Domain A. General Requirements and Challenges
Gateway
To identify the technical requirements and verify the
Installer End concepts, a minimal system of the proposed hybrid WiHA
Installer UI Consumer UI Consumer system architecture is designed as Fig 2. The minimal system is
basically formed of three modules: a Home Gateway, a Cloud
Wide Area Network
Home WSAN Server, User Interface (UI), and a series of sensors and
Home IT Network actuators connected through Home WSAN. The users (end
Home Wireless Network consumers or installers) can connect to the Cloud Server or the
Human Machine Interaction
Control Flow of Cloud‐
Home Gateway directly from their UIs e.g. a smart phone or
Based Mode (Consumer) tablet, depending on user’s choice and the network connection.
Sensors & Actuators
End To accomplish the propose architecture, the Home WSAN is
Consumer
required to provide IP connectivity over low power and low
Fig. 1. The proposed hybrid WiHA architecture and example control flows of
cost short range wireless communication. The 6LoWPAN
Cloud-Based Mode technology is selected due to its native support of IPv6
connectivity and low power wireless capabilities.
Between the Home Automation Gateway and the Home IT
B. Home Gateway
Gateway, secured home IT network should be used such as
WiFi and Ethernet with end-to-end security. In the minimal system, the Home Gateway represents the
Home Automation Gateway and the Home IT Gateway of the
D. Operations of Stand-Alone Mode proposed hybrid architecture. It comprises five modules: the
server communication module, local communication module,
In the Stand-Alone Mode, the Consumer UI joints the control model and database.
Home WSAN under the supervision of the Home Automation
Gateway. Direct two-way communications between the • Server Communication Module: This module is used to
Consumer UI and sensors and actuators are possible in the so- receive the operation command from the Cloud Server and
called peer-to-peer mode. Or otherwise, the communications transmit the required data to the Cloud Server. It also
between Consumer UI and sensors and actuators are handed maintains a long polling connection to the cloud server, i.e.
through the Home Automation Gateway in the so-called the Home Gateway periodically sends requests of data to
centralized mode. the Cloud Server. In case the Home Gateway is in a private
network guarded by firewalls, this request will ask the
E. Operations of Cloud-Based Mode firewall to open the “door” for the target Cloud Server for a
certain period (e.g. minutes) to allow the Cloud Server to
The end consumers can access the sensor and actuators
send data to the Home Gateway. Period polling requests
remotely e.g. when they are travelling or at office. The
will keep the door open which makes it possible that the
monitoring of the status is less critical and allowed to go from
Cloud Server can access the WSAN devices timely
the Home Automation Gateway, through the Home IT
whenever the users want since the “door” is already
Gateway and the public cloud directly to the Consumer UI.
“opened”.
However the control flow is more crucial and not allowed to
simply go through the public cloud. • Local Communication Module: This module manages the
connection between the Home Automation Gateway and
F. Cross-Domain Service Integration User Interface when they are in the same private network.
In industrial practice, the HA System Integrator can choose This module runs a daemon thread to response to any
to provide only basic HA services like field installation, requests from the User Interface e.g. to check the existence
configuration, remote monitoring, and remote control of the of the Home Gateway.
field devices. More advanced services can be provided by the • Web Interface Module: It is a simple web interface to allow
3rd parties or traditionally IT service providers. The proposed the direct operation on this gateway, as long as the
Cloud Server
• User Communication Module: It receives the request from
UIs and transmits respond data to users. It uses customized
Cloud interface to secure the connection from the mobile
Main Module
Database
applications on UIs.
Gateway Mobile
Communication Communication • Gateway Communication Module: It is used for the
Module Module connection between the Home Gateway and the Cloud
Server. In case the Home Gateway is behind a firewall in a
private network, the transactions between the Cloud Server
User
Interface
Installer Home Gateway can only be imitated by the Home Gateway
UI
by the aforementioned long polling scheme.
Installer
Is there a
Private or Public
Home Gateway? • Database: It stores users’ information such as the IP
Network
Consumer address of every user’s home gateway. If authorized by the
UI
End user, it is also possible to store the data and history record
Long
Polling
Consumer of every sensor and actuator. But the amount of history data
is limited because 1) the memory and storage on the home
Home Gateway gateway is limited, and 2) this can reduce the potential loss
Server
Local caused by any security issue.
Communication
Communication
Module
Module
D. User Interface
Web Interface
Module A User Interface could be user’s smart phone, tablet, or
Local
Database
laptop running the Consumer UI of Installer UI applications.
Control Module From user’s point-of-view, there are three possible scenarios as
described below:
Home WSAN
• Scenario 1: The User Interface and the Home Gateway are
not in the same private network. Under this situation, the
User Interface needs to connect to the Cloud Server by the
application on the mobile devices.
• Scenario 2: The User Interface and the Home Gateway are
in a regular private network. The application on user’s
Sensors & Actuators
mobile devices will scan the current private network, try to
Fig. 2. A minimal system of the proposed hybrid WiHA architecture build the connection to the Local Communication Module
in the Home Gateway. It is worthwhile to point out that
users can also choose to connect to the Cloud Server under
credential and authentication information is provided
this situation upon their interests. The choice is left to user
correctly.
to decide.
• Control Module: This module is used to control the sensors
• Scenario 3: This is a special case where even though the
and actuators. It receives the data and event from every
User Interface and the Home Gateway are in the same
sensor in the network, and transmit the operation command
private network, the scanning operation in the Scenario 2 is
to the actuators from the Cloud Server and the Local
not permitted due to the firewall policy. This is quite
Communication Module.
common in the enterprise private network. Under this
• Database: Every Home Automation Gateway runs a local situation, the administration is needed to check the Home
database. It stores the credential and authentication Gateway’s IP first, then it is still possible to control the
information, MAC addresses, current status of all the Home Gateway and the sensors and actuators remotely
sensors in this network, and the history data required from through the Web Interface on the Home Gateway.
users.
E. Implementation of a Prototype
C. Cloud Server As a part of the work in progress, a prototype of the
In the minimal system, the Cloud Server represents the minimal system is being implemented. Some of the hardware
servers of the HA System Integrators and IT service providers setup is shown in Fig. 3. Details are descripted below.
of the proposed hybrid architecture. It comprises four modules:
• Home WSAN Devices: The 6LoWPAN devices from
the User Communication Module, Gateway Communication
Watteco NKE Electronics are selected to implement the
Module, Main Module and Database.
WSAN devices. Two smart plugs and one CO2 detector are
• Main Module: It is the main logic of the program on the used in the prototype system. All the devices are operates at
Cloud Server. It combines the User Communication 868MHz ISM band. The IPv6 adaptation layer is based on
Module and Gateway Communication Module together, the IETF 6LoWPAN standard. The IETF RPL (routing
and directs the data from the database to right IP address. protocol of the IPv6 packets over low-power and lossy
Fig. 4. CO2 measurements collected over a normal working day
V. PRELIMINARY RESULTS
A. Functional Tests
Functional tests have been carried out by two test cases.
The 1st test case is regular access to the WSAN devices. In this
Fig. 3 Implemented hardware of the Home HA Gateway, CO2 detector and case, the user issues some basic commands to control the
two smart plugs 6LoWPAN devices, e.g. turning on/off a smart plug, reading
the current measurement of the smart plug and the CO2
network) protocol is used for mesh networking. In the detector, and enrolling a new devices to the network. . The
application layer, the ZigBee Cluster Library (ZCL) format commands are delivered to the devices and the corresponding
packets are inserted as the payload of UDP packets. Besides measurement data is correctly replied. As an example, CO2
the sensor devices, a USB 6LoWPAN Border Router is measurements are collected over a normal working day and
used to provide the radio connection between the Home shown in Fig. 4.
Gateway and the sensor devices. It can be plugged on a
Linux host and creates the link between standard IPv6 The 2nd test case is to seek the Home Gateway in three type
applications and 6LoWPAN devices. It also takes the role of network environments: 1) the Home Gateway is in a private
to setup the WSAN and in turn to allow new devices network where the firewall allows port scan, 2) the Home
joining in. Gateway is in the private network of our laboratory where the
firewall doesn’t allow port scan, and 3) the Home Gateway is
• Home Gateway: A low cost Linus host, Raspberry Pi, is in 3G network. In the 1st network environment, the User
used to implement the Home Gateway. It has 512 MB of Interface can find the Home Gateway successfully and the
RAM, two USB ports and a 100Mb Ethernet port. The gateway IP is returned. In the 2nd and 3rd network environment,
Raspbian Image is used as the gateway operating system. the User Interface cannot find the Home Gateway and the IP
The Server Communication Module, Local Communication address can only be configured to the User Interface manually.
Module and Control Module are implemented as Python This consist with the design.
program. A Python network engine is designed in the
program. The Database is based on SQLite database B. Performance Tests
running on the Raspberry Pi. A simple Web Interfaces is
Response time is one of the primary concerns when IP-
also provided. After giving the right user name and
based communication is applied due to the lack of real-time
password, users can have a direct control to the WSAN
mechanisms. In this work, two types of Round Trip Time
devices. The Home Gateway application integrates IPv4
(RTT) are measured:
socket and IPv6 socket harmoniously. The IPv4 socket
manages the communication with the Could Server, as well • Ping Command RTT: it starts from the moment when the
as responds to the HTTP request from the Web Interface. User Interface sends out a Ping command to one WSAN
The IPv6 socket manages the connection to the USB device, and ends at the moment when the User Interface
6LoWPAN Border Router not only to control the devices receives a response from the device.
within the WSAN but also to enroll a new devices to the
network. • Application Command RTT: it starts from the moment
when the User Interface sends out an application command
• Cloud Server: The Cloud Server program runs on the such as Read or Write to one WSAN device, and ends at the
Amazon AWS EC2 platform. The server image is in the moment when the User Interface receives a response from
Ireland Region. The service type is t2.micro which contains the device.
one virtual CPU, 1 GiB memory and 8 GB storage. The
server program is based on the Python-Twisted Network Some of the data captured from an experiment in an office
Engine which has better support to asynchronous environment are plotted in Fig. 4 and further analyzed in Table
programming and network event handling. A MySQL 1. In this experiment, the Ping Command RTT and Read
database and a Web Interface are provided as well. Command RTT of the three devices (CO2 sensor, Smart Plug
1, and Smart Plug 2) are sampled sequentially and periodically.
• User Interfaces: By the time this paper was written, we The sampling period is 1 second and the experiment covers
have not finished all the parts of UI applications on the around 3 hours in the evening when the employees are going to
mobile devices. A core part of the UI has been done which leave office. Only the RTTs of the CO2 sensor are plotted
enables the scanning of current network to look for the since the RTTs of other two devices show the same pattern.
Home Gateway. From the plotted data in Fig. 4, it is observed the Ping
(WiHA) systems. They both have pros and cons and a hybrid
RTT(ms)
6 00
4 00
mode architecture is demanded by practitioners in the HA
2 00 industry. In this paper, a hybrid architecture which can support
4 98 0 4 99 0 5 00 0 5 01 0 5 02 0 5 03 0 5 04 0 5 05 0
the both modes flexibility. In the proposed architecture, all IP-
based WSAN technology is applied to ease the device
RTT(ms)
6 00
4 00 integration and service integration. Security concerns are taken
2 00
4 98 0 4 99 0 5 00 0 5 01 0 5 02 0 5 03 0 5 04 0 5 05 0
into account by forbidding the control flow that directly comes
from public cloud. The HA System Integrator should be
involved to accomplish more advanced HA services which
Ping command RTT of CO2 Detector
helps to balance the control and benefit distribution through the
RTT(ms)
60 0
40 0
value chain.
20 0
A proof-of-principle minimal system and prototype are
0 10 00 20 00 30 00 40 00 50 00 60 00 70 00 80 00 90 00 10 000
Time (s)
implemented. The preliminary results of functional test
Read command RTT of CO2 Detector confirms the feasibility of the proposed architecture but the
response time of the wireless protocol is too big compared with
RTT(ms)
60 0
40 0 practical HA system requirements. This is one of the important

20 0 research directions in the next step.
0 10 00 20 00 30 00 40 00 50 00 60 00 70 00 80 00 90 00 10 000
Time (s)
REFERENCES
Fig. 4. Round Trip Time (RTT) time of Ping Command and Read Command
of the CO2 sensor [1] Zhibo Pang, “Technologies and Architectures of the Internet-of-Things
(IoT) for Health and Well-being”, PhD Thesis, Royal Institure of
Table 1. Statistics of the Application Command RTT of three WSAN devices Technology (KTH), Stockholm, Sweden, 2013.
CO2 sensor Smart Plug 1 Smart Plug 2 [2] Langhammer, N. ; Kays, R. "Performance Evaluation of Wireless Home
Min RTT (ms) 175.0 174.0 174.0 Automation Networks in Indoor Scenarios", Smart Grid, IEEE
Average RTT (ms) 207.6 206.9 207.0 Transactions on, Vol.3, Iss4 DOI: 10.1109/TSG.2012.2208770, Page(s):
2252- 2261, 2012
Max RTT (ms) 622.0 650.0 635.0
Sigma (ms) 39.0 39.5 40.6 [3] ZigBee, www.zigbee.org Online accessed on Oct 21, 2014
PDR@1 sigma 87.12% 88.11% 88.78% [4] Mulligan, Geoff Sreenan, Cormac, J. “The 6LoWPAN Architecture”,
PDR@2 sigma 94.52% 94.77% 94.98% Embedded networked sensors: Proceedings of the 4th workshop,
PDR@3 sigma 97.44% 97.48% 97.44% (EmNets ’07) pp.78-82, 2007
[5] EnOcean, www.enocean.org, Online accessed on Oct 21, 2014
[6] KNX-RF, www.knx.org, Online accessed on Oct 21, 2014
Command RTT and Application Command RTT have the [7] DECT ULE, www.ulealiance.org, Online accessed on Oct 21, 2014
similar pattern over time, i.e. when Ping Command RTT is [8] Low Power WiFi, www.wifi.org, Online accessed on Oct 21, 2014
larger, the Application Command RTT is also larger. This [9] Bluetooth Low Energy, www.bluetooth.org, Online accessed on Oct 21,
suggests the RTT is mainly caused by the latency of packet 2014
transmission rather than the processing of data or execution of [10] The Thread Group, http://threadgroup.org Online accessed on Oct 21,
command. From the statistic of the three devices, it is observed 2014
that the three devices have similar response time which is [11] Introduction of Apple HomeKit, http://m.imore.com/homekit-ios-8-
within the range from 147ms to 650ms with an average around explained Online accessed on Oct 21, 2014
207ms. If we set the bound of Maximum Acceptable RTT as [12] ABB, Bosch, Cisco, LG joint press release on consortium for Smart
(Average RTT+1*Standard Deviation), about 88% of the Home, http://www.bosch.lt/en/lt/newsroom_17/news_16/news-detail-
page_38208.php
responses can meet this requirement. This is demoted as PDR
[13] C. Gomez and J. Paradells, “Wireless home automation network: A
(packet delivery rate) @1 Sigma in Table 1. Similarly, about survey of architectures and technologies”, IEEE Communications
95% and 97% percent of the responses can be received within Magazine, vol.48(6,)pp.92-101, Jun. 2010
(Average RTT+2*Standard Deviation) and (Average [14] Olteanu, Alexandru-Corneliu, Oprina, George-Daniel, Tapus, Nicolae,
RTT+3*Standard Deviation) respectively. Zeisberg, Sven, “Enabling Mobile Devices for Home Automation Using
ZigBee”, 2013 19th International Conference on Control Systems and
The above results cannot fully meet the practical Computer Science, pp. 189-195 May 2013
requirements of HA systems according to the role of thumb [15] A. R. Al-Ali and M. Al-Rousan, "Java-based home automation system",
which expects most (e.g. over 95%) of the responses should IEEE Transactions on Consumer Electronics, vol. 50, no. 2, pp. 498-
arrive with 150ms. This has indicated that, to reduce the 504, 2004.
network latency of 6LoWPAN is one of the important research [16] Khusvinder Gill, Shuang-Hua Yang, Fang Yao, Xin Lu, “A ZigBee-
direction in the next step. Moreover, another planned work in Based Home Automation System”, IEEE Transactions on Consumer
Electronics, pp.422-430, May 2009
progress is the tests of RTTs of the Cloud-Based Mode when a
[17] S. Ok and H. Park, "Implementation of initial provisioning function for
Cloud Server in public cloud like Amazon is used. home gateway based on open service gateway initiative platform", The
8th International Conference on Advanced Communication Technology,
VI. CONCLUSION pp. 1517-1520, 2006.
Cloud-Based Mode and Stand-Alone Mode are the two

typical networking architecture of Wireless Home Automation
Preliminary Study on Industry-Friendly and Native-IP
Wireless Communications for Building Automation
Zhibo Pang1, Yuxin Cheng2, Morgan E. Johansson1, Gargi Bag1
1, Corporate Research, ABB AB, Västerås, Sweden
2, ICT School, Royal Institute of Technology (KTH), Stockholm, Sweden
{pang.zhibo|morgan.e.johansson|gargi.bag}@se.abb.com, yuxinc@kth.se
Abstract—Wireless communication technologies for building much faster. In practical standardization efforts, the evolution
automation (BA) systems are evolving towards native IP towards NIP connectivity has been clearly observed in most of
connectivity. More Industry Friendly and Native-IP Wireless the established or emerging BA communication standards, both
Building Automation (IF-NIP WiBA) is needed to address the wireless and wired, e.g. BACnet has released the BACnet/IP
concerns of the entire value chain of the BA industry including [3], KNX has released the KNXnet/IP [4], ZigBee has released
the security, reliability, latency, power consumption, engineering the ZigBee IP [5], Bluetooth is developing the 6LoWPAN-
process, and independency. In this paper, the vision, over-BLE [6], and DECT ULE is developing the 6LoWPAN-
requirements, and gaps of existing efforts are reviewed first. over-ULE [7]. Given the standards which already have NIP
Then a hybrid architecture which can seamless support both
connectivity such as the IEEE802.11ah Low Power WiFi [8],
Cloud-Based Mode and Stand-Alone Mode is introduced based
on the 6LoWPAN WSAN (wireless sensor and actuator
Thread Group [9], and the IETF IoT Suite (6LoWPAN, RPL,
networks) technology and verified by a prototyping minimal and CoAP) [10], the BA industry has reached a common
system. The preliminary experimental results suggest that, 1) consensus to enter the NIP era in near future even though the
both the WSAN and Cloud communications can meet the landscape of standardization is till fragmented.
requirements of non-real-time application of BA systems, 2) the To realize this vision of NIP-based WiBA, in addition to
reliability and latency of the WSAN communications is not the technical challenges about reliability, latency, power
sufficient for soft real-time applications but it is not far away to
consumption, and complexity, some important concerns from
meet such requirements by sufficient optimization in the near
the standpoint of value chain should be addressed, e.g. “Is that
future, 3) the reliability of Cloud is pretty sufficient but the
latency is quite far from the requirement of soft real-time
a good idea to connect everything in buildings to internet or
applications. To optimize the latency and power consumption in cloud? How to reduce the security and privacy risks when
WSAN, design industrial friendly engineering process, and enjoy the benefits from IP connectivity? How to inherit the
investigate security mechanisms should be the main focus in the experiences, best practices and tools for engineering and
future. commissioning? How to strengthen their roles in the existing
value chain which seems potentially to be disrupted by new
Keywords—Fog-of-Things (FoT); Wireless Sensor and entrants?” In other words, the BA industry is demanding an
Actuator Networks (WSAN); 6LoWPAN; Native IP Connectivity Industry-Friendly and Native IP (IF-NIP) communication
(NIP); Wireless Building Automation (WiBA) architecture which will not only meet the critical technical
performances but also take care the business benefits of all the
I. INTRODUCTION stakeholders in the value chain. However the existing efforts in
this direction are insufficient due to the misinterpretation of
Building Automation (BA) for residential buildings or “NIP connectivity”, or lack of friendliness to system integrators
homes, commercial buildings, and industrial buildings is one of and installers, or lack of support to engineering workflow (see
the most promising application area of the Internet-of-Things section II for more details).
(IoT) [1]. Thanks to the reduced cost of installation and
maintenance and improved user experiences, Wireless Sensor As a work in progress, this paper intends to present some
and Actuator Network (WSAN) technologies are being preliminary thoughts and findings towards the vision of IF-NIP
actively applied or developed and therefore the Wireless WiBA systems. In particular, the concerns of BA industry are
Building Automation (WiBA) has become the new design interpreted from the standpoint of the whole value chain, and
paradigm of future BA systems [2]. To bring native support of gaps of existing efforts are identified. Then the vision of IF-
Internet Protocol (IP), the so-called Native IP (NIP), to NIP WiBA is introduced and motivated. As a natural and
lightweight WSAN devices is a promising direction of the specific derivative of this vision, a hybrid communication
evolution of communication technologies for BA systems. It architecture is proposed to support flexible combination of
can not only ease the interoperability challenges during the Cloud-Based Mode and Stand-Alone Mode. Preliminary
system integration of various devices, sub-systems, and value- experimental results of a prototyping minimal system based on
added services from different suppliers, but also tear down the 6LoWPAN are presented with special respects with latency
walls that are hindering the BA industry to benefit from the and reliability. The technical feasibility of the proposed
vast amount of innovations in internet domain which evolves architecture for non-real-time applications is confirmed and the
needs of improvement for soft real time applications are
suggested as well. Ongoing work about security, power industry has reached the consensus towards NIP networks, the
consumption, and engineering process are discussed but market penetration of wireless NIP technology are still not
without experimental results since they are out of the scope of satisfactory. Besides the insufficient technical maturity of the
this paper. This paper has figured out a visionary outline standards, the lack of friendliness to the established value chain
towards the next generation wireless communication is pointed to be one of the root causes. In other words, an
architecture for future building automation systems. The Industry-Friendly and Native IP (IF-NIP) wireless
industrial friendly considerations of the proposed vision and communication solution for building automation systems is not
architecture can accelerate the market penetration since the in place today. This has motivated our vision of the so-called
major concerns of the entire industrial value chain are IF-NIP WiBA. In an IF-NIP WiBA solution, the wireless
addressed better. communications should basically provide the same level of
performances as the wired NIP technologies in terms of
The rest of the paper is organized as follows: in Section II security, reliability, and soft real-time, and additionally provide
the vision, requirements, and gaps of existing efforts are years of battery life or even battery-free operation. At the same
interpreted, and the hybrid architecture is briefly introduced as time, the IF-NIP WiBA solution should be compatible with the
well. The design and implementation of a proof-of-concept best engineering practices during system integration,
minimal system are presented in Section III. In Section IV, commissioning, and maintenance. These requirements and
preliminary experimental results with respect to the latency and gaps of existing efforts are detailed below.
reliability are given. Finally the paper is concluded in Section
V.
C. Buildings in the Fog-of-Things
II. THE VISION, REQUIREMENTS, AND GAPS Compared with many other applications of IoT in consumer
domains, the BA system is much more critical in terms of
A. Evolution towards the NIP for BA Systems determinism, safety, security, and privacy. The term of
Internet-of-Things, Intranet-of-Things, or Industrial Internet
The two de facto standards of wired communication for BA are misleading according to our experience when communicate
systems, the BACnet and KNX, have both released the NIP with customers. Therefore we propose a new term of Fog-of-
edition BACnet/IP [3] and KNXnet/IP [4] respectively and Things (FoT) (inspired by the concept of Fog Computing
achieved successful market acceptance. The evolution towards introduced by Cisco [14]) to avoid misunderstanding,
NIP is also clearly observed in the established or emerging emphasize crucial requirements, and be more friendly to
wireless standards. First, the wireless technologies which industrial practitioners. First, it is obvious that FoT is not
already support NIP is trying to reduce the complexity, power always to connect everything to the internet or cloud. Instead,
consumption, and cost so as to be suitable for lightweight in many cases, the networked devices can also be connected to
WSAN devices. For example, the WiFi Alliance has a plan to isolated local networks or intranet. Second, the fog (the
release a low power version IEEE802.11ah which works at interconnected intelligence devices) is seamlessly surrounding
sub-1GHz band dedicatedly for WSAN and IoT applications on the ground (the physical objects in field) unlike the cloud
[11]. The IETF is trying to finish the application layer which is far away floating over the ground. So the FoT is a
specification CoAP (Constrained Application Protocol) so as to better representation of the characteristics of IoT in critical
provide a complete IoT Suite [12]. Second, the WSAN applications, including the wireless connectivity, close loop
technologies which currently don’t support NIP are turning to control, embedded decision making, short latency, high
NIP by embracing the 6LoWPAN (IPv6 over Low power reliability, high mobility, location awareness, and wide-spread
Wireless Personal Area Networks). For example, the ZigBee geographical distribution. Third, professionals with industrial
Alliance has released the new generation specification of expertise become even more important than ever to make such
ZigBee IP [5] based on the 6LoWPAN and RPL protocols FoT systems work in the field, which essentially strengthen the
defined by IETF. The Bluetooth SIG has started to define the roles of system integrators and installers. Therefore it a more
so-called 6LoWPAN-over-BLE together with IETF [6] based industrial friendly term.
on the Bluetooth v4.1. Moreover, the DECT ULE is also
working on their NIP version [7]. Given the facts, the IETF D. Technical Requirements and Gaps
6LoWPAN (IPv6 over Low power Wireless Personal Area
Networks) and RPL (IPv6 Routing Protocol for Low power Given the requirements of future building automation
and Lossy Networks) protocols have become the de facto systems under the context of FoT, we see after decades of
standards of the transformation towards NIP [10]. It is valuable efforts, the wired NIP technologies like BACnet/IP and
to mention, the battery-free EnOcean technology also supports KNXnet/IP have achieved acceptable performances of latency,
IP but it is not looked as NIP since the EnOcean-over-IP reliability, and security at least for commercial buildings which
gateway is needed [13]. KNX-RF is not NIP either since the are less cost-sensitive compared with residential buildings and
RF/TP or RF/IP coupler is needed to interoperate with IP less mission-critical compared with industrial buildings. But
network [4]. the wireless NIP technologies cannot yet reach the same level
of performances as the wired NIP technologies [15, 16]. So the
B. The Vision of IF-NIP WiBA IF-NIP WiBA system must address the following technical
challenges simultaneously.
Given the above technical survey of the established and
emerging standards and deep market survey throughout the • Security: Security is always the primary concern in any
entire value chain, we have observed that, although the BA industrial communication system including the WiBA
system. For an extreme example, a hacker or terrorist might system integrators and installers. In particular the following
send a command to start all the heavy loads (e.g. air requirements must be met.
conditioners) at the same moment to trigger an accident or
trip of the distribution grid. Such commands should • Engineering Process: The BA industry has established
definitely be filtered or blocked by the WiBA systems. At mature engineering process and tools based on the decades
the same time, the privacy concerns from end consumers of best practices. For example, the KNX Association has
are also important challenge faced by the suppliers when standardized the engineering tool software ETS and
everything is connected by wireless because attack can be standardized device description file format. The
performed without physical access and the loss caused by configuration parameters are described in such files by the
the attack can be exponentially enlarged if it is connected to device manufacturer in a machine readable language. The
internet. system integrator can conveniently configure the
parameters after import this file to the ETS software, and
• Reliability: The fundamental limit of the reliability is the interoperability of devices from different manufacturers are
interferences and distortions of radio signals are also guaranteed by this means [4]. This process has been
complicated and highly dynamic due to the open nature of praised as one of the best practices. KNX-RF naturally
wireless media. Moreover the reliability of RPL as the de supports this engineering process but unfortunately it is not
facto routing protocol of wireless NIP today is not NIP, The EnOcean is going to define the similar
satisfactory under the interference of a typical home or engineering tools and file formats but unfortunately it is not
office environment [17]. NIP either [20]. Actually none of the existing wireless NIP
technologies can meet this requirement. Although most of
• Latency: The latency is fundamentally limited by the them intend to provide a cloud-based autonomous service
physical layer bandwidth. Compared with the phical layer discovery and configuration solution [21], the
bandwidth of wired NIP technologies which is typically standardization progress is unclear. And we are doubtful
100Mbps, the bandwidth of radios used in the wireless NIP about the effectiveness in practice because 1) it increases
standards is too narrow e.g. up to 250Kbps for ZigBee IP the dependency of cloud infrastructure and services which
and IETF IoT Suite, 1Mbps for Bluetooth LE, and is conflicting with the next requirement below, and 2) it
1.152Mbps for DEC ULE. According to our experimental significantly increase security vulnerabilities since the users
results (see section IV), the latency of wireless NIP is too are blind to the process.
long compared with the rule-of-thumb of Soft Real-Time for
non-critical control application that suggests a maximum • Independency: An essential approach to keep the health of
Round Trip Time (RTT) of 150ms. In more critical cases the BA value chain is to ensure the independency of the
such as the future sustainable buildings as a part of Micro players. On one hand, the system integrator and installer
Grids. Many control loops in such buildings require don’t want the WiBA system to rely on other infrastructure
bounded latency and guaranteed availability to manage the or services which are controlled by 3rd parties, e.g. the
power generation, storage, and consumption. cloud service provided by the device manufactures or
telecom operators. On the other hand, end users especially
• Power Consumption: Unlike the wired NIP devices, most commercial users, don’t like to tie their WiBA systems to
of the WiBA devices are expected to be battery-powered or one more contract with a 3rd party to reduce the business
even battery-free to fully deliver the benefits of being complexity and security and privacy issues. Some popular
“really wireless”. So the above critical requirements must solutions in DIY market cannot meet this requirement. For
be met under the strict constraints of battery life e.g. no less example, the HomeKit platform provided by Apple requires
than 3 years for non-permanently working devices. It is all the configuration information to be distributed by the
even desirable to have battery-free wireless NIP devices. It iCloud service provided by Apple. To realize any remote
is challenging but the work in [18] has demonstrated the control of the HomeKit-enabled WSAN devices, an iOS
possibility of transmitting 6LoWPAN packets from a terminal like the iPhone, iPad, or AppleTV box is needed
WSAN device powered by piezoelectric-based energy [19].
harvesting.
F. Industry Friendliness of Cloud-Based vs. Stand-Alone
E. Non-Technical Requirements and Gaps
Established BA system suppliers which have rooted deeply
In nowadays BA value chain, system integrators and in the value chain still emphasize the so-called Stand-Alone
installers are playing essential roles to help the device Mode where the WiBA devices are interconnected to each
manufacturers to reach end users or consumers. They integrate other directly or through a kind of local gateway, and users can
the devices into a usable solution by performing the monitor and control the devices locally without any
complicated parameterization, configuration, installation, and involvement of internet or cloud server. First, it gets rid of the
commissioning according to the specific requirements of the dependency of internet and cloud services, and therefore the
users. Even though the do-it-yourself (DIY) market is issues about security and privacy can be significantly reduced.
developing quickly driven by some new entrants from out of Second, the installation and configuration of such devices are
BA domain like the Apple HomeKit [19], the role of system more complicated for end users than Cloud-Based Mode. Thus,
integrators and installers should be strengthened instead of the role of system integrators and installers are strengthened by
weakened. So the IF-NIP WiBA system must be friendly to technical means. So it is looked as more industry-friendly.
Cloud Server
Cloud
Main Module
Database
Gateway Mobile UI
Communication Communication
Module Module
CO2 PP M in an office
8 00
User
Installer
C O2 P P M
7 00
Interface
UI 6 00
5 00
Installer 4 00
Is there a 8 10 12 14 16 18
Private or Public Time O'clock

Home Gateway?
Network
Consumer
Data recorded in the database
UI
End
Long Consumer
Polling Fig. 2 Implemented hardware of the minimal system including the Cloud
Server, User Interface, Automation Gateway, and the WSAN devices, and the
Automation
Gateway
CO2 measurements collected over a normal working day in the office building
Local
Server
Communication
Communication
Module
Module operation, and flexible combination of the two basic modes.
Benefited from the Cloud-Based Mode, the system integrators
Web Interface
Module can choose to provide remote services for engineering,
Local commissioning, command validation, and maintenance by
Database
Control Module themselves through a private cloud, and they can choose to
partner with 3rd parties for more value-added services like
energy management and optimization, in home healthcare, and
WSAN many more. Benefited from the Stand-Alone Mode, they can
also choose to perform the engineering, commissioning, and
maintenance in the field by professional installers utilizing
exactly the same workflow as the wired BA systems so that the
security issues and dependency can be minimized.
Additionally, they can combine the Cloud-Based Mode and
Sensors & Actuators Stand-Alone Mode in a more flexible way, e.g. using the
Fig. 1. A minimal system of the proposed hybrid IF-NIP WiBA architecture Cloud-Based Mode during commissioning to ease the
engineering and configuration and using the Stand-Alone
Some solutions from new entrants have significantly Mode after commissioning.
simplified the configuration and commissioning efforts by the
so-called Cloud-Based Mode where the WSAN devices of the III. PROTOTYPES
WiBA system are all connected to a kind of server in the cloud
and users can monitor and control the devices through the A. Design of a Minimal System
internet during configuration as well as usage. Traditional
system integrators and installers become less important since To identify the technical requirements and verify the
all these work can also be done by the end users themselves, or concepts, a minimal system of the proposed hybrid IF-NIP
the device manufacture if the cloud services are included in the WiBA system architecture is designed as Fig 1. The minimal
product package, or the another service provider like telecom system is basically formed of four elements: an Automation
operators. So it is looked as not industry-friendly enough. Gateway, a Cloud Server, a User Interface (UI), and a series of
sensors and actuators connected through WSAN. The users
(end consumers or installers) can connect to the Cloud Server
G. The Hybrid Architecture or the Automation Gateway directly from their UIs e.g. a smart
Given the pros and cons of the Cloud-Based Mode and phone or tablet, depending on user’s choice and the network
Stand-Alone Mode, the BA industry is demanding a hybrid connection. The 6LoWPAN technology is used in the WSAN
WiBA architecture which can take the advantages of the both for native support of IPv6 connectivity over low power
modes i.e. to simplify the system configuration and wireless communications. More details of the minimal system
maintenance by the Cloud-Based Mode, to reduce the security is given in [22].
and privacy issues by the Stand-Alone Mode, and to make the
solution more friendly to both system integrators, installers, B. Implementation of the Prototype
and dedicated service providers by offering flexible
combination of the two modes. A prototype of the minimal system is being implemented.
Some of the hardware setup is shown in Fig. 2. Details are
The hybrid architecture for the IF-NIP-WIBA has been descripted below.
proposed in our previous work [22]. It can seamlessly support
both Cloud-Based Mode operation, Stand-Alone Mode • Cloud Server: The Cloud Sever application runs in an
Ubuntu 12.04 image on Amazon AWS EC2 Platform. The
service type is t2.micro, which contains one virtual CPU, 1
GiB memory along with 8 GB store. The server program is
written in Python. It forwards any HTTP request (GET,
POST) from the web interface to the Automation Gateway,
and then sends the received HTTP response from the
Automation Gateway back to users.
• User Interfaces: A static webpage is implemented as the
User Interface of our system. From the table in the
webpage, users can identify the sensors’ name, as well as
the IPv6 address, network connection status, average
latency within the local WSAN network. Users can also
control the sensors from the webpage. In our case, users can
turn on/off a smart plug, get the current measurement from
CO2 detector, etc. There is no difference between the user
interface on cloud server and the user interface on
automation gateway. Users can have the same controlling
command on both user interfaces.
• Automation Gateway: A low cost Linus host, Raspberry Pi,
is used to implement the Automation Gateway. It has 512
MB of RAM, two USB ports and a 100Mb Ethernet port.
The Raspbian Image is used as the gateway operating
system. The Server Communication Module, Local Fig. 3. Test setup in the office building
Communication Module and Control Module are
implemented as Python program. A Python network engine User Cloud Automation 1st Hop 2nd Hop 3rd Hop
is designed in the program. The Database is based on Interface Server Gateway Device Device Device
SQLite database running on the Raspberry Pi. A simple
Web Interfaces is also provided. After giving the right user
name and password, users can have a direct control to the RTTUI‐h1 RTTGW‐h1
WSAN devices. The Automation Gateway application
integrates IPv4 socket and IPv6 socket harmoniously. The
IPv4 socket manages the communication with the Could
Server, as well as responds to the HTTP request from the RTTUI‐h2 RTTGW‐h2
Web Interface. The IPv6 socket manages the connection to
the USB 6LoWPAN Border Router not only to control the
devices within the WSAN but also to enroll a new devices
to the network. In the Automation Gateway program, a
daemon thread is set to monitor the current network status RTTUI‐h3 RTTGW‐h3
of the sensor, measuring the average latency of every sensor
within the local sensor network.
• WSAN Devices: The 6LoWPAN devices from Watteco Fig. 4. Definition of Round Trip Time (RTT) between UI and Gateway and
NKE Electronics are selected to implement the WSAN between Gateway and Devices with different number of hops
devices. Two smart plugs and one CO2 detector are used in
the prototype system. All the devices are operates at
868MHz ISM band. The IPv6 adaptation layer is based on
IV. PRELIMINARY RESULTS
the IETF 6LoWPAN standard. The IETF RPL (routing
protocol of the IPv6 packets over low-power and lossy
A. Experiment Setup
network) protocol is used for mesh networking. In the
application layer, the ZigBee Cluster Library (ZCL) format As mentioned, latency and reliability are of the concerns
packets are inserted as the payload of UDP packets. Besides when IP-based communication is applied due to the lack of
the sensor devices, a USB 6LoWPAN Border Router is real-time mechanisms. As shown in Fig.3, the hardware is
used to provide the radio connection between the setup in a corridor of our office building which is about 100
Automation Gateway and the sensor devices. It can be meters long, and the Automation Gateway is installed in the
plugged on a Linux host and creates the link between office aside. The WSAN is configured to be three hops. The
standard IPv6 applications and 6LoWPAN devices. It also Cloud Server which is deployed on the Amazon PaaS located
takes the role to setup the WSAN and in turn to allow new in Ireland.
devices joining in.
RTTGW RTTUI
Fig. 5. Round Trip Time between Gateway and Devices (RTTGW) and between User Interface and Devices (RTTUI), and their histograms
Device sends out its response, then the response forwarded

B. Definition of Evaluation Criteria by the 2nd hop Device and 1st hop Device sequentially back
In this experiment, the latency is measured by Round Trip to the Automation Gateway, finally the Automation
Time (RTT). As shown in Fig. 4, two types of RTTs are Gateway receives the response and records the time
defined. The RTTs are denoted by the number of hops in the duration as RTTGW-hop3.
WSAN. For example, the RTT between the User Interface and
the 3rd hop device is denoted as RTTUI-h3. They a Reliability is measured by the Round Trip Packet Error
Rate (RT-PER) which is the percentage of the commands that
• RTTUI: it starts from the moment when the User Interface are not responded correctly before timeout among the total
sends out a command to one of the WSAN devices, and commands sent during the period of test. The RT-PER are
ends at the moment when the User Interface receives a measured at the User Interface and Automation Gateway and
response from the device. During the test, the User denoted as RT-PERUI and RT-PERGW respectively.
Interface software sends out a command to e.g. the 3rd hop
Device, then the command is forwarded by the Cloud C. Data Analysis
Server, Automation Gateway, 1st hop Device, and 2nd hop
Device sequentially to the 3rd hop Device, then the 3rd hop The test results from an experiment that lasted for about 15
Device sends out its response, then the response forwarded hours are plotted in Fig. 5 and statistics of the data is collected
by the 2nd hop Device, 1st hop Device, Automation in Table I. Some observations are described below.
Gateway and Cloud Server sequentially back to the User • Latency of WSAN. RTTGW represents the latency caused by
Interface, finally the User Interface receives the response the communications within the WSAN. 1) The average
and records the time duration as RTTUI-hop3. RTTGW is on the order of hundreds of milliseconds, e.g.
• RTTGW: it starts from the moment when the Automation 184ms, 324ms and 465ms for 1st, 2nd hop, and 3rd hop
Gateway sends out a command such as Read or Write to respectively in this experiment. 2) The average RTTGW
one of the WSAN device, and ends at the moment when the increases proximately linearly when the number of hops
Automation Gateway receives a response from the device. increases. In experiment, the average RTTGW increases by
During the test, the Automation Gateway software sends 140ms for each hop. 3) The distribution of RTTGW is quite
out a command to e.g. the 3rd hop Device, then the diverse. In experiment, the maximum RTTGW is on the
command is forwarded by the 1st hop Device, and 2nd hop order of seconds and 4 to 5 times larger than the average
Device sequentially to the 3rd hop Device, then the 3rd hop RTTGW.
Table I. Statistics of the Round Trip Time (RTT) and Round Trip Packet Error • Reliability of Cloud. The RT-PERUI represents the total
Rate (RT-PER) command failure caused by the communications within
1st Hop 2nd Hop 3rd Hop Cloud and WSAN. Because in this experiment, the
communications between the Cloud Server and User
Device Device Device
Interface and the Automation Gateway are based on TCP
RTTUI Min(ms) 2247.2 2354.1 2463.9 which has automatic retransmission and guaranteed end-to-
Average(ms) 2347.1 2473.6 2612.4 end reliability, there is no command failure caused by the
Max(ms) 4300.7 3849.9 4061.6 Cloud in fact. So the RT-PERUI is equal to the RT-PERGW
σ (ms) 94.3 118.7 123.2 in this experiment.
avg+σ (ms) 2441.4 2592.3 2735.6
avg+2σ (ms) 2535.7 2711 2858.8 D. Performance Assessment
avg+3σ (ms) 2630 2829.7 2982 • Communications of WSAN. For non-real-time applications
P@avg+σ 91.41% 91.63% 88.83% through local network, such as monitoring of status of
sensors and configuration of operation parameters (e.g.
P@avg+2σ 97.43% 96.86% 97.43%
schedule, work mode) of actuators by an in-home display
P@avg+3σ 98.68% 98.17% 99.00%
(IHD) or smart phone, the latency and reliability of WSAN
RTTGW Min(ms) 154 258 364 communications is acceptable. For example, in this
Average(ms) 184 324 465 experiment if we set the up bound of Maximum Acceptable
Max(ms) 846 1531 1950 RTT as 768ms which is the Average_RTTGW+
σ (ms) 47 96 101 3*Standard_Deviation of the furthest away 3rd hop devices,
avg+σ (ms) 231 420 566
about 95.68% of the commands can receive correct
responses, and 99.59% of the responses arrives within.
avg+2σ (ms) 278 516 667
However this cannot meet the requirement of soft real time
avg+3σ (ms) 325 612 768 applications such as remote control of dimmerable lights or
P@avg+σ 89.76% 91.58% 86.52% curtains which need the latency to be imperceptible for
P@avg+2σ 95.13% 97.35% 97.78% human. According to the rule-of-thumb in practice,
P@avg+3σ 97.87% 98.58% 99.59% imperceptible latency usually is defined as >95% of the
RTTCloud Average(ms) 2163.1 2149.6 2147.4
commands are responded correctly within 150ms. In this
experiment, even for the nearest 1st hop device, 95.13% of
RT-PERUI % 0.00% 3.15% 4.32% the responses arrive within 278ms. But it is not far from the
RT-PERGW % 0.00% 3.15% 4.32% acceptable level.
• Latency of Cloud. The RTTUI represents the total latency • Communications of Cloud. The reliability of Cloud
caused by the communications in the WSAN and Cloud. In communications is pretty good for most of the applications.
this experiment, it is reasonable to assume that the statistic But the latency can only meet the requirement for non-real-
characteristics of the WSAN and Cloud environment is time applications. It is quite far (10 time larger) from the
stable during the period of the two commands for RTTGW requirements of soft real-time applications.
and RTTUI because they are sent almost at the same
moment (the error is less than sub second). So the average E. Limitations and Future Work
latency cause by the Cloud (RTTCloud) can be proximately Due to the limitation of time, the proposed engineering
estimated by average(RTTUI )- average(RTTGW). 1) The process is not fully implemented on the prototype and therefore
average RTTCloud is quite stable and not affected by the is out of the scope of this paper, but is one of the focus of the
number of hops in WSAN. In this experiment, the average ongoing work. Another ongoing work is to evaluate and
RTTCloud is all around 2000s for 1st hop, 2nd hop, and 3rd hop optimize the power consumption of the WSAN devices and
devices. 2) The distribution of RTTUI is less diverse Automation Gateway. As mentioned above, the WSAN latency
compared with the RTTUI. In this experiment, the maximum cannot meet the requirement of soft real-time applications, but
RTTUI is always less than twice of the minimum RTTUI. 3) it is not far away, therefore we expect to solve it in the next
Occupying the major part of the total latency, the latency of step of our work. But since the latency of Cloud is quite far
Cloud is 4 to 10 times larger than the WSAN latency. away for soft real-time applications, to optimize the latency in
• Reliability of WSAN. The RT-PERGW represents the Cloud will not be the focus in our next step. Instead, we will
command failure caused by the communications within the look more into security issues and solutions of the Cloud
WSAN. The RT-PERGW increases when the number of hop communications.
increases. In this experiment, we not have observed any
command failure for the 1st hop device. However we are not V. CONCLUSION
sure about whether there is no packet loss because we are Future building automation systems are typical practical
not clear if there is any re-transmission mechanism in the cases of the Fog-of-Things (FoT) which represents the IoT for
lower layers of the protocol implemented by the Watteco more critical applications. Wireless communication
devices. The RT-PERGW increase up to 3.15% and 4.32% at technologies for building automation systems are evolving
the 2nd hop device and 3rd hop device respectively. towards native IP connectivity. To realize the vision of
Industry Friendly and Native-IP Wireless Building Automation edition of the MCC workshop on Mobile cloud computing (MCC '12),
(IF-NIP WiBA) systems, more industry friendly wireless August 2012
communication technology is needed to address the concerns [14] EnOcean Alliance, "EnOcean Alliance Advances Support for IP-Based
Wireless Energy Harvesting Sensor and Control Technologies", 2011
of the entire value chain of the BA industry, including the
[15] Konstantin Mikhaylov,Nikolaos Plevritakis and Jouni Tervonen,
security, reliability, latency, power consumption, engineering "Performance Analysis and Comparison of Bluetooth Low Energy with
process, and independency. IEEE 802.15.4 and SimpliciTI", Journal of Sensor and Actuator
Networks, 2013, 2, 589-613; doi:10.3390/jsan2030589
In this paper, the vision, requirements, and gaps of existing
[16] Langhammer, N. ; Kays, R."Performance Evaluation of Wireless Home
efforts are reviewed first. Then a hybrid architecture which can Automation Networks in Indoor Scenarios", Smart Grid, IEEE
seamless support both Cloud-Based Mode and Stand-Alone Transactions on,Volume:3,Issue:4,DOI: 10.1109/TSG.2012.2208770,
Mode is introduced based on the 6LoWPAN technology and 2012 , Page(s): 2252- 2261
verified by a prototyping minimal system. The preliminary [17] Dong Han ; Gnawali, O. "Performance of RPL under wireless
experimental results suggest that, 1) both the WSAN and interference", Communications Magazine, IEEE, Volume:51, Issue:12
Cloud communications can meet the requirements of non-real- DOI:10.1109/MCOM.2013.6685769: 2013 , Page(s): 137- 143
time application of BA systems, 2) the reliability and latency of [18] Zimmermann, T. ; Frey, A. ; Schreiter, M. ; Seidel, J. ; Kuehne, I.
"MEMS-based piezoelectric energy harvesting modules for distributed
the WSAN communications is not sufficient for soft real-time automotive tire sensors", Systems, Signals and Devices (SSD), 2012 9th
applications but it is not far away to meet such requirements by International Multi-Conference on, DOI: 10.1109/SSD.2012.6198097,
sufficient optimization in the near future, 3) the reliability of 2012,1-4
Cloud is pretty sufficient but the latency is quite far from the [19] HomeKit-Apple Developer, https://developer.apple.com/homekit, online
requirement of soft real-time applications. accessed on Nov 10, 2014
[20] EnOcean Alliance, "EnOcean Alliance defines intelligent
In the next step of this work, to optimize the latency and commissioning of smart buildings", July 2, 2014
power consumption in WSAN, implement industrial friendly [21] Cirani, S. ; Davoli, L. ; Ferrari, G. ; Leone, R. ; Medagliani, P. ; Picone,
engineering process, and investigate security mechanisms M. ; Veltri, L. "A Scalable and Self-Configuring Architecture for
should be the main focus. Service Discovery in the Internet of Things", Internet of Things Journal,
IEEE,Vol:1,Issue:5,DOI:10.1109/JIOT.2014.2358296,2014,508- 521
[22] Zhibo Pang, Yuxin Cheng, Morgan E. Johansson, Gargi Bag,
REFERENCES "Preliminary Study on Wireless Home Automation Systems with Both
[1] Zhibo Pang, “Technologies and Architectures of the Internet-of-Things Cloud-Based Mode and Stand-Alone Mode", to appear in the 13th IEEE
(IoT) for Health and Well-being”, PhD Thesis, Royal Institure of Int. Conf. on Ubiquitous Computing and Communications, Dec 2014.
Technology (KTH), Stockholm, Sweden, 2013. [23] Christopher Mims, "Forget 'the Cloud'; 'the Fog' Is Tech's Future",The
[2] Langhammer, N. ; Kays, R. "Performance Evaluation of Wireless Home Wall Street Journal, May 18, 2014
Automation Networks in Indoor Scenarios", Smart Grid, IEEE
Transactions on, Vol.3, Iss4 DOI: 10.1109/TSG.2012.2208770, Page(s):
2252- 2261, 2012
[3] BACnet Offical Website, www.bacnet.org, Online accessed on Oct 21,
2014
[4] Michele Ruta, Floriano Scioscia, Giuseppe Loseto, Eugenio Di Sciascio,
"KNX, a worldwide standard protocol for home and building
automation: state of the art and perspectives", Industrial Communication
Technology Handbook, CRC Press/Taylor & Francis, page 1463--1481 -
aug 2014
[5] ZigBee Alliance, "ZigBee IP Specification (ZigBee Public Document
13-002r00)", February 2013
[6] IETF 6Lo Working Group, "Transmission of IPv6 Packets over
BLUETOOTH(R) Low Energy (draft-ietf-6lo-btle-03)", September 1,
2014
[7] IETF 6Lo Working Group, " Transmission of IPv6 Packets over DECT
Ultra Low Energy (draft-mariager-6lowpan-v6over-dect-ule-03)", July
15, 2013
[8] Low Power WiFi, www.wifi.org, Online accessed on Oct 21, 2014
[9] The Thread Group, http://threadgroup.org Online accessed on Oct 21,
2014
[10] Palattella, M.R. ; Accettura, N. ; Vilajosana, X. ; Watteyne, T. ; Grieco,
L.A. ; Boggia, G. ; Dohler, M. "Standardized Protocol Stack for the
Internet of (Important) Things", Communications Surveys & Tutorials,
IEEE, Vol 15, Issue: 3, DOI: 10.1109/SURV.2012.111412.00158, 2013
[11] Weiping Sun, Munhwan Choi and Sunghyun Choi, "IEEE 802.11ah: A
Long Range 802.11 WLAN at Sub 1 GHz", Journal of ICT
Standardization, Vol. 1, 83–108. doi: 10.13052/jicts2245-800X .125,
2013
[12] IETF CoRE Working Group, "Constrained Application Protocol (CoAP)
(draft-ietf-core-coap-18)", June 28, 2013
[13] Flavio Bonomi, Rodolfo Milito, Jiang Zhu, Sateesh Addepalli, “Fog
computing and its role in the internet of things” Proceedings of the first

Von Meier

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Von Meier

Загружено:

Авторское право:

Доступные форматы

Home Automation System Design And

Implementation Based On 6LoWPAN

Hemautomationssystem är smarta enheter som möjliggör olika funktioner i ett

2 The 6LoWPAN Protocol 17

3 Related Study on Home Automation System 20

4 System Architecture Design 22

6 Results and Analysis 32

7 Conclusions and Future Work 44

6LoWPAN IPv6 and Low Power Wireless Premise Area Networks

Despite of different companies’ products, from the devices’ perspective, there

What we design and implement is a double-mode system architecture, where

In chapter 3 we did the literature study of home automation system. Different

In chapter 4, we propose the two-mode hybrid architecture of home automa-

Chapter 5 gives the detailed implementation of the hybrid home automation

In chapter 7, we conclude the project work and the future work.

6LoWPAN is a developing standard from the Internet Engineering Task Force

2.2 Features of 6LoWPAN

The Dispatch Header:

The Mesh Header:

Figure 1: 6LoWPAN Header[1]

2.3 6LoWPAN vs. ZigBee

[3][5][6][7] give more technical comparison of ZigBee and 6LoWPAN. It is shown

These systems have made a great contribution to the development of home

[12] provides a cloud-enabled home automation system based on UPnP over

3.2 Requirements of Home Automation System

Reliability of home automation device and home automation system is both

Power Consumption needs to be taken into consideration, especially for those

Figure 2: System Architecture

4.2 Home Gateway

Cloud-Sever Communication Module: This module is used to receive the

4.3 Cloud Server

Gateway Communication Module: This module is used for the connec-

Database: This module contains user’s information, such as the IP of user’s

4.4 User Interface

Figure 3: System Modules

Figure 4: Hardware Devices in the System Implemtation

Besides the 6LoWPAN smart devices, a USBStickRF-BorderRouter is provided

5.3 Raspberry Pi Home Gateway Application

5.3.2 Home Gateway Application

5.4 Amazon EC2 Cloud Server

5.5.2 Latency Measurement and Retransmission

Figure 6: CO2 PPM in an office

6.2 Performance Tests

6.2.2 Stand-alone Mode with Single Hop

Table 1: Statistics of the Application RTT of three Devices

6.2.3 Stand-alone Mode with Multi-Hop

Table 2: Statistics of the System RTT of Three Hops 6LoWPAN Network

6.2.4 Cloud Server Mode with Multi-Hop

Table 3: Statistics of the RTT of Three Hops 6LoWPAN Network in Cloud

However, from the protocol perspective, 6LoWPAN is still a quite promising

IV. DESING OF A MINIMAL SYSTEM

40 0 practical HA system requirements. This is one of the important

Cloud-Based Mode and Stand-Alone Mode are the two

Private or Public Time O'clock

Device sends out its response, then the response forwarded

Вам также может понравиться