Home Automation System Design And Implementation Based On 6LoWPAN

(1)

Home Automation System Design And Implementation Based On 6LoWPAN

YUXIN CHENG

2015.1

(2)

(3)

Abstract

Home automation systems are collections of smart devices that enable various 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 communication 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 architecture 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.

(4)

(5)

Abstrakt

Hemautomationssystem är smarta enheter som möjliggör olika funktioner i ett hus eller en byggnad, s˚asom kontroll av ljus och uttag, energiövervakning, tem- peraturmätning, luftkonditionering och uppvärmning, etc. Dessa enheter är vanligtvis smarta sensorer, implementerade med l˚ageffekt kommunikationspro- tokoll som ZigBee och 6LoWPAN som endast kan styras via en Internet-gateway.

Numera finns det flera hemautomationprodukter p˚a marknaden. Användaren kan med sin smarta telefon styra sina produkter. Kommandot g˚ar via en molnbaserad server och vidarebefordras till motsvarande gateway, kommandot n˚ar slutligen till sensoranordningarna, även kallat ”molnbaserat läge”.

Detta ”molnbaserade läge” är inte effektiv under vissa omständigheter där in- ternetanslutning ej är tillänglig. I detta avhandlingsarbete föresl˚as, genomförs och utvärderas en hybrid systemarkitektur som inkluderar b˚ade stand-only och molnbaserade läget. Detta erbjuder en snabb anslutning när användarens smartphone och sensor gateway är p˚ar samma privata nätverk. Den föreslagna systemarkitekturen passar användarens behov och ger hög tillförlitlighet.

(6)

(7)

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.

(8)

(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

(11)

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

(12)

(13)

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

(14)

(15)

1 Introduction

1.1 Purpose

In a smart home automation system, various of smart sensor devices are connected 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 access 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 devices from smart phone or tablet whenever and wherever. However, the communication 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 connection 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.

(16)

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 different functionalities of the devices are tested, and the performance tests, where the round-trip time (RTT) from different test scenarios are collected and calculated. The RTT is an important parameter in system evaluation and the RTT result will be influence by certain different variables. To build a successful system 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 architecture of 6LoWPAN protocol is shown. Second, we introduce some important features of 6LoWPAN. Third, we compare 6LoWPAN to another famous protocol 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 automation 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 devices, 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.

(17)

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 protocols. Third, since all network protocol stack are IP based, there are existed standards such as UDP, TCP, ICMP, DNS and existed services like load balancing, 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.

(18)

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 standard 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 standard 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

(19)

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 network 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 2ˆ64 network size and ZigBee support up to 65K.

(20)

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] developed 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 between 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 indirectly. 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

(21)

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 automation 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.

(22)

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 communication 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.

(23)

Local Communication Module: This module allows the connection between the home gateway and user end node when they are in the same private network. 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 credential 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 module, 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 connection 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 module 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

(24)

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 application 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 gateway. 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 connect 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 administration 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

(25)

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

(26)

5.2 Watteco 6LoWPAN Devices

For our two-mode system architecture home automation system implementation, 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 devices 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 networking (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 cluster. 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

(27)

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 address 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 received, the home gateway will ask the control module to do the requested work (e.g. ’switch1=on’). Meanwhile, the current status will be replied.

(28)

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 remote 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

(29)

automation gateway.

(30)

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 limited 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 device. 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 connection 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 automation 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 application 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 networks, 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

(31)

time (RTT) result and analysis can be found in the next chapter.

(32)

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 increase 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

(33)

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 acknowledgement 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.

(34)

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.

(35)

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 (average 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%

(36)

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.

(37)

Figure 10: 3 Hops 6LoWPAN Network in Office Corridor

Similar to the last subchapter, we also collected RTT as the system performance 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 network, 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.

(38)

Figure 11: System Ping of the First Device

(39)

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%

(40)

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.

(41)

Figure 14: RTT of the First Hop Device in Cloud Server Mode

(42)

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 Packet Delivery Rate of (average RTT+1*Sigma) 91.41% 91.63% 88.83%

(43)

Figure 16: RTT of the Third Hop Device in Cloud Server Mode

(44)

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.

(45)

(46)

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.

(47)

(48)

8 Appendix

(49)

Preliminary Study on Wireless Home Automation Systems with Both Cloud-Based Mode and Stand-

Alone Mode

Zhibo Pang¹, Yuxin Cheng², Morgan E. Johansson¹, Gargi Bag¹ 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 numerous industries including consumer electronics, telecom, internet, and building automation, a Home Automation (HA) system requires flexible wireless communication architecture to not only take the advantages of wireless technologies such as reduced cost of installation and maintenance and improved user experiences but also fulfill the concerns of various industrial stakeholders. From this point-of-view, neither the pure Cloud- Based nor the Stand-Alone architecture is sufficient. In this paper, an IP-based hybrid architecture is presented which can support flexible combination of Could-Based Mode and Stand- Alone Mode. Preliminary prototyping based on the 6LoWPAN and experimental evaluation of performances have indicated the technical feasibility as well as future directions of improvement.

Keywords—Internet-of-Things (IoT); Wireless Sensor and Actuator Networks (WSAN); 6LoWPAN; Cloud-Based Mode, Stand-Alone Mode; Home Automation (HA)

I. INTRODUCTION

As digital representation of real world, the Internet-of- Things (IoT) integrates all kinds of sensing, control, identification, communication, networking, and informatics devices and systems, and seamlessly connects all the people and things upon interests, so that anybody, at any time and any place, through any device and media, can more efficiently access the information of any object and any service [1]. The Home Automation (HA) is one of the most promising application area of the IoT. Thanks to the reduced cost of installation and maintenance and improved user experiences, Wireless Sensor and Actuator Network (WSAN) technologies are being actively applied or developed [2]. Some of these technologies that have gained much attention include the ZigBee Pro [3], ZigBee IP [3], IETF 6LoWPAN (IPv6 over Low power Wireless Personal Area Networks) [4], EnOcean [5], KNX-RF[6], DECT ULE [7], Low Power WiFi [8], Bluetooth Low Energy [9], and Thread [10]. The designers of Wireless Home Automation (WiHA) systems have to manage the challenges caused by the diverse requirements from different stakeholders in the value chain because the Smart Home segment is an intersection of numerous industries

communication architecture is also required to support both Cloud-Based Mode and Stand-Alone Mode.

In particular, in the Cloud-Based Mode, the WSAN devices of the WiHA system are all connected to a kind of server in the cloud and users can monitor and control the devices through the internet during configuration as well as usage. In the Stand- Alone Mode, the devices are interconnected to each other directly or through a kind of local gateway, and users can monitor and control the devices locally without any involvement of internet or cloud server. The Cloud-Based Mode can reduce the effort for end consumer to install, configure and manage the WiHA devices since all these work are done either by the device manufacture if the cloud services are also included in the product package, or by the a dedicated service provider. It is usually preferred in the do-it-yourself (DIY) market driven by new entrains from out of HA industry like the Google Nest[10] and Apple HomeKit [11] and telecom or broadcast service providers. However it is not sufficiently friendly to the system integrators and installers which play essential roles in the value chain of HA industry. Moreover, the security and privacy concerns from end consumers are also important challenge faced by the suppliers. In contrast to the Cloud-Based Mode, the Stand-Alone Mode gets rid of the dependency of internet and cloud services. By doing this with proper cyber security techniques, the issues about security and privacy can be significantly reduced. As an expense, the installation and configuration of WiHA devices are more complicated for end consumers compared to usual consumer electronic devices and the WiHA devices in Cloud-Based Mode. In practice, the installation and configuration work is usually done by professionals of system integrator or installers.

Therefore the Stand-Alone Mode is looked as friendlier to system integrators and installers since they can keep their essential roles in the value chain, and it is usually preferred by the established HA system suppliers which have rooted deeply in the HA value chain [12].

Given the pros and cons of the Cloud-Based Mode and Stand-Alone Mode, the HA industry is demanding a hybrid architecture which can take the advantages of the both modes i.e. to simplify the system configuration and maintenance by

(50)

dedicated service providers by offering flexible combination of the two modes. However, the existing research on this is insufficient from the point-of-view of HA industry (see section II).

In this paper, an IP-based hybrid architecture for WiHA systems which can seamlessly integrate both the Cloud-Based Mode and Stand-Alone Mode with minimized cost to switch between the two modes. A prototype is implemented based on the 6LoWPAN which brings native IP compatibility to low power and low cost wireless WiHA devices. A scalable gateway architecture which can be deployed both on low cost embedded devices in the homes or on high performance servers in the cloud is designed. A prototype system is implemented and experimental tests are carried out with a focus on the timing performances. The preliminary results have confirmed the technical feasibility of the proposed architecture but the round trip time, typically 207ms for 1 hop WSAN, is still too long compared with the practical HA system requirements.

This will be an important direction of future research.

The rest of the paper is organized as follows: in Section II related works are reviewed from system architecture perspective. In Section III the proposed hybrid system architecture is introduced. The design of a minimal system and implementation of a prototype are presented in Section IV. In Section V, preliminary experimental results with respect to the response time are given. Finally the paper is concluded in Section VI.

II. RELATED WORK

There exist a significant research work done with respect the communication architecture of WiHA systems [13]. For example, Olteanu et al. provided a home automation system where users can control ZigBee devices from their mobile phones and tablets [14]. The mobile devices can either control the ZigBee devices directly, or with a USB dongle, or through the public Internet. Al-Ali and Al-Rousan developed a Java based home automation system [15]. All the home automation devices are connected to an embedded board physically and a Java web server is used to provide remote access to the system.

Gill et al. proposed and implemented a ZigBee home automation system where a home gateway provides interoperability between the local ZigBee and Wi-Fi network work and the Internet [16]. Ok and Park proposed a OSGI (Open Service Gateway Initiative), which home automation system for administration and maintenance can be accessed from service provider [17]. These systems have made a great contribution to the development of home automation system design. However, the authors have observed a gap between industrial practice and academic work. First, the architecture prosed in the literatures is lack of harmonization of Cloud- Based Mode and Stand-Alone Mode, i.e. they either focus on Cloud-Based Mode or focus on Stand-Alone Mode. How to combine the two modes in a single solution is not presented.

Second, the concerns of the HA system integrators and installers are not considered sufficiently which implies the need of re-thinking this question from the point-of-view of

III. SYSTEM ARCHITECTURE

A. Overview

The proposed hybrid WiHA communication architecture that can operate both in Cloud-Based Mode and in Stand- Alone Mode is illustrated in Fig. 1. The key elements of the Smart Home system including the WiHA system are separated into three domains as follows.

 HA Device Domain: It comprises all the field devices of the WiHA system including the sensors and actuators, WSAN network devices (e.g. routers, bridges), home automation gateway, and Consumer User Interface (UI) (e.g. smart phone with apps). The devices in the HA Device Domain are connected by short range wireless communications through the WSAN. In this domain, end consumers can interact with the WiHA directly through the sensors and actuators or through the Consumer UI, which is called the Stand-Alone Mode.

 HA Service Domain: It comprises the backbone system of the HA System Integrator, private cloud infrastructure, and Installer UI (e.g. smart phone with apps). The HA Service Domain is interconnected by private cloud which is intensively safeguarded by firewalls. In this domain, installers can interact with the WiHA devices in field through the Installer UI.

 IT Service Domain: It comprises the backbone system of various IT services (e.g. energy analytics, home service, utility billing, and entertainment), public cloud infrastructure, in-home IT gateway, and Consumer UI.

The IT Service Domain is interconnected by public cloud through wired or wireless wide area network technologies such as 3G/4G, FTTH, Ethernet, HomePlug, etc. In this domain, end consumers can only interact with the WiHA indirectly through the cloud, which is called the Cloud- Based Mode.

B. Domain-Based Access Control

In the proposed architecture, different domain has different level of vulnerability. In the IT Service Domain which is the most vulnerable domain of the WiHA system, hackers can attack the WiHA system remotely from any place of the world in theory. So the it has to be isolated as much as possible and no direct control flow is allowed from the IT Service Domain and the HA Device Domain.

C. Domain-Based Network Integration

The classification of domains makes it convenient to decide the networking technologies of each domain and in between two domains. In the HA Device Domain, to increase the cost of direct invasion to the sensors of actuators, short range wireless communication technologies with sufficient end-to-end security is needed for the Home WSAN. Some of the promising candidates are ZigBee Home Automation, ZigBee IP, and IETF IoT Stack (6LoWPAN, RPL, and CoAP). In the HA Service Domain and IT Service Domain, conventional

(51)

Between the Home Automation Gateway and the Home IT Gateway, secured home IT network should be used such as WiFi and Ethernet with end-to-end security.

D. Operations of Stand-Alone Mode

In the Stand-Alone Mode, the Consumer UI joints the Home WSAN under the supervision of the Home Automation Gateway. Direct two-way communications between the Consumer UI and sensors and actuators are possible in the so- called peer-to-peer mode. Or otherwise, the communications between Consumer UI and sensors and actuators are handed through the Home Automation Gateway in the so-called centralized mode.

E. Operations of Cloud-Based Mode

The end consumers can access the sensor and actuators remotely e.g. when they are travelling or at office. The monitoring of the status is less critical and allowed to go from the Home Automation Gateway, through the Home IT Gateway and the public cloud directly to the Consumer UI.

However the control flow is more crucial and not allowed to simply go through the public cloud.

F. Cross-Domain Service Integration

In industrial practice, the HA System Integrator can choose to provide only basic HA services like field installation,

architecture helps to balance the control and distribution of benefits through the value chain. For example, an energy 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 analytic service provider should get the authentication from the HA System Integrator and install it into the Home IT Gateway accordingly. Otherwise, it is not allowed to control the field devices even though it might be able to read the load data from the field.

IV. DESING OF A MINIMAL SYSTEM

A. General Requirements and Challenges

To identify the technical requirements and verify the concepts, a minimal system of the proposed hybrid WiHA system architecture is designed as Fig 2. The minimal system is basically formed of three modules: a Home Gateway, a Cloud Server, User Interface (UI), and a series of sensors and actuators connected through Home WSAN. The users (end consumers or installers) can connect to the Cloud Server or the Home Gateway directly from their UIs e.g. a smart phone or tablet, depending on user’s choice and the network connection.

To accomplish the propose architecture, the Home WSAN is required to provide IP connectivity over low power and low cost short range wireless communication. The 6LoWPAN technology is selected due to its native support of IPv6 connectivity and low power wireless capabilities.

B. Home Gateway

In the minimal system, the Home Gateway represents the Home Automation Gateway and the Home IT Gateway of the proposed hybrid architecture. It comprises five modules: the server communication module, local communication module, control model and database.

• Server Communication Module: This module is used to receive the operation command from the Cloud Server and transmit the required data to the Cloud Server. It also maintains a long polling connection to the cloud server, i.e.

the Home Gateway periodically sends requests of data to the Cloud Server. In case the Home Gateway is in a private network guarded by firewalls, this request will ask the firewall to open the “door” for the target Cloud Server for a certain period (e.g. minutes) to allow the Cloud Server to send data to the Home Gateway. Period polling requests will keep the door open which makes it possible that the Cloud Server can access the WSAN devices timely whenever the users want since the “door” is already

“opened”.

• Local Communication Module: This module manages the connection between the Home Automation Gateway and User Interface when they are in the same private network.

This module runs a daemon thread to response to any requests from the User Interface e.g. to check the existence of the Home Gateway.

Sensors & Actuators Installer UI

Home WSAN

Installer End

Consumer Home Automation

Gateway Home IT Gateway IT Services

End Consumer HA System

Integrator

Private Cloud

End Consumer Public Cloud

Home Wireless Network Human Machine Interaction Home IT Network

Consumer UI Consumer UI

Wide Area Network

Control Flow of Cloud‐

Based Mode (Consumer)

IT Service Domain HA Service Domain

HA Device Domain

Fig. 1. The proposed hybrid WiHA architecture and example control flows of Cloud-Based Mode

(52)

credential and authentication information is provided correctly.

• Control Module: This module is used to control the sensors and actuators. It receives the data and event from every sensor in the network, and transmit the operation command to the actuators from the Cloud Server and the Local Communication Module.

• Database: Every Home Automation Gateway runs a local database. It stores the credential and authentication information, MAC addresses, current status of all the sensors in this network, and the history data required from users.

C. Cloud Server

In the minimal system, the Cloud Server represents the servers of the HA System Integrators and IT service providers of the proposed hybrid architecture. It comprises four modules:

the User Communication Module, Gateway Communication Module, Main Module and Database.

• Main Module: It is the main logic of the program on the Cloud Server. It combines the User Communication

• User Communication Module: It receives the request from UIs and transmits respond data to users. It uses customized interface to secure the connection from the mobile applications on UIs.

• Gateway Communication Module: It is used for the 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 Home Gateway can only be imitated by the Home Gateway by the aforementioned long polling scheme.

• Database: It stores users’ information such as the IP address of every user’s home gateway. If authorized by the user, it is also possible to store the data and history record of every sensor and actuator. But the amount of history data is limited because 1) the memory and storage on the home gateway is limited, and 2) this can reduce the potential loss caused by any security issue.

D. User Interface

A User Interface could be user’s smart phone, tablet, or laptop running the Consumer UI of Installer UI applications.

From user’s point-of-view, there are three possible scenarios as described below:

• 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 mobile devices will scan the current private network, try to 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 this situation upon their interests. The choice is left to user to decide.

• Scenario 3: This is a special case where even though the User Interface and the Home Gateway are in the same private network, the scanning operation in the Scenario 2 is not permitted due to the firewall policy. This is quite common in the enterprise private network. Under this situation, the administration is needed to check the Home Gateway’s IP first, then it is still possible to control the Home Gateway and the sensors and actuators remotely through the Web Interface on the Home Gateway.

E. Implementation of a Prototype

As a part of the work in progress, a prototype of the minimal system is being implemented. Some of the hardware setup is shown in Fig. 3. Details are descripted below.

• Home WSAN Devices: The 6LoWPAN devices from Watteco NKE Electronics are selected to implement the WSAN 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

Installer

End Consumer User

Interface

Is there a Home Gateway?

Installer UI

Consumer UI

Sensors & Actuators Home WSAN Home Gateway

Control Module Local

Database

Local Communication

Module Server

Communication Module

Web Interface Module Long

Polling

Cloud Server Cloud

Database

Mobile Communication

Module Gateway

Communication Module

Main Module

Private or Public Network

Fig. 2. A minimal system of the proposed hybrid WiHA architecture

Home Automation System Design And Implementation Based On 6LoWPAN