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, energymonitoring, 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 froman Internet gateway. Nowadays, there are lots of home automation products onthe market for customers. User can use application on smart phone to controlthe products they bought. The control command can go through a cloud-basedserver and be directed to the corresponding gateway, and finally reach to thesensor devices, which is referred to as ”cloud-based mode” system.

However, this single mode is not efficient under some circumstances where theInternet is not enabled or allowed. In this thesis work, a hybrid system archi-tecture is proposed, implemented and evaluated, which include both stand-onlyand cloud-based mode. It offers a quick connection when user’s smart phoneand 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 ar smarta enheter som mojliggor olika funktioner i etthus eller en byggnad, sasom kontroll av ljus och uttag, energiovervakning, tem-peraturmatning, luftkonditionering och uppvarmning, etc. Dessa enheter arvanligtvis smarta sensorer, implementerade med lageffekt kommunikationspro-tokoll som ZigBee och 6LoWPAN som endast kan styras via en Internet-gateway.Numera finns det flera hemautomationprodukter pa marknaden. Anvandarenkan med sin smarta telefon styra sina produkter. Kommandot gar via enmolnbaserad server och vidarebefordras till motsvarande gateway, kommandotnar slutligen till sensoranordningarna, aven kallat ”molnbaserat lage”.

Detta ”molnbaserade lage” ar inte effektiv under vissa omstandigheter dar in-ternetanslutning ej ar tillanglig. I detta avhandlingsarbete foreslas, genomforsoch utvarderas en hybrid systemarkitektur som inkluderar bade stand-onlyoch molnbaserade laget. Detta erbjuder en snabb anslutning nar anvandarenssmartphone och sensor gateway ar par samma privata natverk. Den foreslagnasystemarkitekturen passar anvandarens behov och ger hog tillforlitlighet.

5

6

Acknowledgement

I would like thank my parents for their love and support to me. Also I wouldlike thank my supervisors at ABB Corporate Research Center, Dr. Zhibo Pangand Morgan E. Johansson for their great help and patience. Then, I would liketo thank my supervisor and examiner Dr. Jiajia Chen, Assistant Professor atOptical Networks Lab, School of Information and Communication Technology(ICT) KTH for the guidance, supervision and valuable advice. This work ispartially supported by EIT-ICT Lab Project ”M2M and Xhaul”. Finally, mysincere gratitude goes to all my friends, for their love and help to me.

7

8

Contents

1 Introduction 151.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.2 Research Questions and Challenges . . . . . . . . . . . . . . . . . 161.3 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2 The 6LoWPAN Protocol 172.1 Introduction to 6LoWPAN . . . . . . . . . . . . . . . . . . . . . 172.2 Features of 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.1 Headers in 6LoWPAN . . . . . . . . . . . . . . . . . . . . 172.3 6LoWPAN vs. ZigBee . . . . . . . . . . . . . . . . . . . . . . . . 18

3 Related Study on Home Automation System 203.1 Different Studies about Home Automation System . . . . . . . . 203.2 Requirements of Home Automation System . . . . . . . . . . . . 20

4 System Architecture Design 224.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 224.2 Home Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.3 Cloud Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.4 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5 System Implementation 255.1 Introduction to the System Implementation . . . . . . . . . . . . 255.2 Watteco 6LoWPAN Devices . . . . . . . . . . . . . . . . . . . . . 265.3 Raspberry Pi Home Gateway Application . . . . . . . . . . . . . 27

5.3.1 Raspberry Pi . . . . . . . . . . . . . . . . . . . . . . . . . 275.3.2 Home Gateway Application . . . . . . . . . . . . . . . . . 27

5.4 Amazon EC2 Cloud Server . . . . . . . . . . . . . . . . . . . . . 285.5 More about the System Implemtation . . . . . . . . . . . . . . . 30

5.5.1 Long Polling Scheme . . . . . . . . . . . . . . . . . . . . . 305.5.2 Latency Measurement and Retransmission . . . . . . . . . 30

6 Results and Analysis 326.1 Functional Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 326.2 Performance Tests . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.2.1 Introduction of Performance Tests . . . . . . . . . . . . . 336.2.2 Stand-alone Mode with Single Hop . . . . . . . . . . . . . 336.2.3 Stand-alone Mode with Multi-Hop . . . . . . . . . . . . . 366.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] . . . . . . . . . . . . . . . . . . . . . . . . . 182 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 223 System Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 Hardware Devices in the System Implemtation . . . . . . . . . . 255 The Sample Web Interface on the Home Gateway . . . . . . . . . 286 CO2 PPM in an office . . . . . . . . . . . . . . . . . . . . . . . . 327 CO2 Detector RTT . . . . . . . . . . . . . . . . . . . . . . . . . . 348 Partial Data from CO2 Detector . . . . . . . . . . . . . . . . . . 359 Histogram of 3 Devices’ RTT . . . . . . . . . . . . . . . . . . . . 3610 3 Hops 6LoWPAN Network in Office Corridor . . . . . . . . . . . 3711 System Ping of the First Device . . . . . . . . . . . . . . . . . . . 3812 System Ping of the Second Device . . . . . . . . . . . . . . . . . 3913 System Ping of the Third Device . . . . . . . . . . . . . . . . . . 4014 RTT of the First Hop Device in Cloud Server Mode . . . . . . . 4115 RTT of the Second Hop Device in Cloud Server Mode . . . . . . 4216 RTT of the Third Hop Device in Cloud Server Mode . . . . . . . 43

10

List of Tables

1 Statistics of the Application RTT of three Devices . . . . . . . . 352 Statistics of the System RTT of Three Hops 6LoWPAN Network 393 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 NetworksHA Home AutomationIP Internet Protocol

IOT Internet of ThingsAWS Amazon Web ServiceEC2 Elastic Cloud 2PPM Parts Per MillionRTT Round Trip Time

HTTP HyperText Transfer ProtocolDNS Domain Name SystemTCP Transmission Control ProtocolUDP User Datagram ProtocolPDR 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 buytons of different home automation system product on the market today. Usersare able to control their devices from their smart phone or tablet, at or be awayfrom 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, thereare several popular technologies competing for market share. The dominatingcommunication technologies for wireless smart sensors are ZigBee, 6LoWPAN.On the contrary to the high data rate network for multimedia and Internetapplication, 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 ratenetwork for power-limit sensors and devices. The ZigBee network layer and6LoWPAN adaption layer provides different routing mechanism to relay andtransfer the packet. In [1], it is proved that 6LoWPAN is an ideal protocol torealize a uniform addressing scheme for low data rate networks as well as highdata rate networks. In ZigBee IP Specification [2], the ZigBee Alliance providesits open iPv6-based standard, and the 6LoWPAN protocol is also included inZigBee IP protocol stack.

From the system perspective, usually the company will provide a cloud-basedserver 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 believethis 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 controlhis devices, even though he is at his own home. Another example could be thatin a big hotel where hundreds of smart plugs are implemented, a centralizedcontrol 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, wherenot only the cloud-server is provided, but stand-alone mode is allowed when theuser-end (smart phone, tablets, etc) and the smart devices are within the sameinternal network. Users can choose their preference whether cloud-based severor 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 automationsystem based on the current third party devices from Watteco. The protocolstack of the Watteco devices is studied in order to implement the application onthe home gateway. Meanwhile, enabling the cloud server mode requires certainmechanism to penetrate the private network firewall. To evaluate the systemperformance results, we separate into two categories: functional test where dif-ferent functionalities of the devices are tested, and the performance tests, wherethe round-trip time (RTT) from different test scenarios are collected and calcu-lated. The RTT is an important parameter in system evaluation and the RTTresult will be influence by certain different variables. To build a successful sys-tem where a desirable RTT is reached, these different variables that can changethe 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 importantfeatures 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. Differenthome automation systems are compared. We also conclude and propose therequirements 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 thesethree modules are shown and expained into details.

Chapter 5 gives the detailed implementation of the hybrid home automationsystem demo. We explain the different technical mechanism in the Wattaco de-vices, home gateway application as well as the application running on AmazonEC2 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 RTTof the devices in stand-alone mode. For the cloud server mode, we test the multihop 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 topof 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 ableto translate between different application protocols of sensors and the standardInternet Protocol. Second, using IP based protocols, users can employ differenttools that are already developed for configuring ,debugging networks. Thereis 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 existedstandards such as UDP, TCP, ICMP, DNS and existed services like load balanc-ing, caching, firewall that are enable for network programmer and developers tochoose and use.

6LoWPAN is a developing standard from the Internet Engineering Task Force(IETF) 6LoWPAN Working Group. The standard is designed to enable thetraditional IP running on the sensors. However, traditional IPv6 packets aretoo expensive to the regular sensors. The IPv6 packet header is 40 bytes whilethe MTU of 802.15.4 frame is 127 bytes.[4] Thus, a certain head compressionmechanism 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 headerto 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. Thefollowing 6 bit represent whether it is a IPv6 uncompressed header (000001) orIPv6 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 layersource and destination of the packet. It includes two single bit fields to indicatewhether the address is a short or long address, since 802.15.4 standards allowsboth 16 bit short addresses and standard 64 bit addresses. The next 4 bit fieldis 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 ofpayload), the fragmentation and reassemble need to be supported. In the firstfragment header, the data size and the datagram tag, and the following fragmentheader also includes the datagram offset. Although in most sensor network, theapplication 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 Allianceholds the brand mark of ZigBee along with tons of ZigBee products. Same as6LoWPAN, it also utilizes IEEE standard 802.15.4 standard. From the point ofinteroperability, the ZigBee devices can interoperate with other ZigBee devices.But in order to communicates with non-ZigBee network, the ZigBee devicesneed an application layer gateway to translate different protocols. 6LoWPAN,on the other hand, offers interoperability with other wireless 802.15.4 devices aswell 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 32Kbytes 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 6LoWPANonly 4K is required. The header overhead of ZigBee is 8 to 16 bytes, while theheader of 6LoWPAN is 2 to 11 bytes. For the network size, 6LoWPAN support264 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] providesa home automation system where users can control ZigBee devices from theirmobile phones and tablets. The mobile devices can either control the ZigBeedevices directly, or with a USB dongle, or through the public Internet. [9] devel-oped a Java based home automation system. All the home automation devicesare connected to an embedded board physically and a Java web sever is usedto provide remote access to the system. [10]proposed and implement a ZigBeehome automation system where a home gateway provides interoperability be-tween the local ZigBee and Wi-Fi network work and the Internet. [11]proposeda OSGI (Open Service Gateway Initiative), which home automation system foradministration and maintenance can be accessed from service provider.

These systems have made a great contribution to the development of homeautomation system design. However, it is mentioned in the last chapter, allhome automation system based on ZigBee required a gateway or device coordi-nator to translate the different protocol used in the sensor’s network and outsideinternet 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 overIPv4/IPv6 and 6LoWPAN. The gateway supports the traditional IPv4 inter-facing over WiFi or Ethernet. However, only cloud-based mode is supportedaccording to this paper. [13] gives a brief introduction of 6LoWPAN devicesdesign and the interactions between 6LoWPAN devices and home automationsystem defined by users. This paper mainly focus on the downside 6LoWPANdevice 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 requirementslike security, reliability, latency and power consumption that need to be takeninto 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 offeatures in the home automation system design. Confidentiality means that allthe user’s data, user’s sensor’s data should be well stored and no one else butuser can have the access to them. Authentication should be done in the controlof 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 bothimportant. 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 thework 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, cloudserver, as well as the signal transmission time. The bandwidth of the channelthat devices are using will limit the latency. The retransmission mechanismbetween device and gateway or the gateway between the cloud server will makethe total latency of one user behavior differ a lot.

Power Consumption needs to be taken into consideration, especially for thosewireless devices in the sensor network. The battery life is a strict parameter ofthe wireless devices. A good battery life will in turn increase the reliability andthe latency of the system. The low power device might increase the transmissiontime, 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 systemis described. The system is outlined in Fig 2. The system is basically formedof three modules: the Home Gateway Module, the Cloud Sever Module, andthe User node Module. The user can connect to cloud-base server or the homegateway directly from their smart phone or tablet, depending on user’s choiceand 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 theoperation command from the cloud server side and transmit the required datato the cloud sever. This module also maintain the long pulling connection tothe sever, so that regular firewall policy will not be violated. A PING-PONGscheme 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 betweenthe 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’ existencecheck request from the user end node within the same private network. Thismodule also runs a simple web interface to allow the direct operation on thisgateway, as long as the credential and authentication information is providedcorrectly.

Control Module: This module is used control the smart sensors. It receivesthe data and event from every sensor in the network, and transmit the operationcommand 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 thesensors 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 usernode and respond the request data to user. It uses our self-defined interfacesfor 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 possiblethat the home gateway is behind a firewall and it is not possible to initial theconnection from the server side, the long polling scheme is used the hold up theconnection. Also a PING-PONG scheme is used to report the aliveness of thehome 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’shome gateway. After getting user’s permission, it also contains the data of everysensor and history record, since the memory and storage on the home gatewayis limited.

4.4 User Interface

A user node module could be user’s smart phone, tablet, laptop. We providesa 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. Underthis 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. Theapplication on user’s mobile devices will scan the current private network, tryto build the connection to the local communication model on the home gate-way. The home gateway daemon thread will listen and respond the request fromthe 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 homegateway are in the same private network, the scanning step in the last scenariois not permitted due to the firewall policy reason. This is quite possible in acompany’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 tocontrol the gateway and the sensors remotely by the web interfaces on the homegateway.

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 thesystem modules in the last chapter. We have 6LoWPAN-supported smart homedevices from Watteco, including two smart plugs and one CO2 detector, as wellas a 6LoWPAN border router. We used a Raspberry Pi with a Raspbian imageas 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 andone CO2 detector are used in our implementation. All the devices are wirelessand communicate using Radio Frequency (RF) at 868MHz (ISM band). The de-vices implement recent IETF networking 6LoWPAN standards for compressedIPv6 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 tothe devices. More information of the application of the Wattaco devices can befound in their User Guid.[14]

Besides the 6LoWPAN smart devices, a USBStickRF-BorderRouter is providedfrom Watteco. It can be plugged on a Linux host and creates the link betweenstandard IPv6 applications and 6LoWPAN devices. It is also in a role to openthe sensor network, which in turn to allow the new devices joining in.

There are three devices used in the home automation system: two smart plugand a CO2 sensor:

Smart Plug:

In the application layer of the smart plug, two main cluster is included besidesthe basic cluster: On/Off Cluster and Simple Metering Cluster. The On/Offcluster allows the control and management to turn on or off the current smartplug, or simple reverse the on/off state. The simple metering cluster is supposedto 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 smartplug is simple incorrect. The on/off cluster, on the other hand, is correctlyimplemented.

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 toprovide 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 increasein 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 into relative IPv6 address based on the configuration of the boarder router. Moreinformation 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 ofRAM, two USB ports and a 100Mb Ethernet port. We use the Raspbian Imageas the gateway operating system. Raspbian is a Linux operating system basedon 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, thereare server different IP address need to be clear for the readers. In the RaspberryPi home gateway application, there is an IPv6 address and an IPv4 address. Thehome gateway application is running as a server to the 6LoWPAN devices, andas a client to the cloud server in the home automation system. Thus, the IPv6address 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 webengine 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 tosend and receive IPv6 packets from and to the 6LoWPAN devices. The data issaved in a database, which in this case is just a simple TXT file for the simplifythe 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 threedevices, such as the IPv6 address, current network connection state, currentaverage latency as well as the control to the devices such as turn on/off asmart plug, get the current measurement of the CO2 devices. When there isa ’GET’ HTTP request received, the home gateway application will reply thewebpage 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 orderto save the cost, the type is t2.micro, which contains one virtual CPU, 1 GiBmemory and 8 GB on storage is chosen as the running server instance. Thecloud server application is also written in python. It listens to the port 80 of itspublic IP, and 8080 as the port communicating to the home gateway. In thisthesis work, only minimum work is done at the server part. When an HTTPrequest (GET, POST) is received at the cloud server, it forwards it to the homegateway 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 realtime measurement graph to the user, or multi home gateway supported. In thiswork, only one home gateway is supported, due to the reason of lack enoughdevices. Second, the real cloud services provide by AWS can be used in thehome automation system. The AWS EC2 provides many easy-to-use servicesto their costumer, such as load balancing, auto scaling up/down, etc. The useof cloud service in home automation is beyond this thesis work, but can bedone in the future. In this work, the cloud server application simply works asa proxy, between the user and the home automation gateway, when the userdevices (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 initiala request to the cloud server. This is due to the reason that most gateway isin a private network, it is impossible for a cloud server with a public IP otherthan the private network IP to initial the connection. After the connection isbuilt, the home gateway will send an IP packet with payload of ’PING’ to theserver every 3-5min and the server will reply a ’PONG’ message in the sameway. The is so-called ”PING PONG” mechanism, and it not only shows thealiveness of home gateway and the cloud server to each other, but keep thesocket 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 thesocket will be closed after certain idle time. The long polling scheme keeps thesocket 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 gatewayand the devices. There are thread that keep pinging each devices every tenseconds. The home gateway application will refresh the average latency basedon 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 6LoWPANnetworks. However, there is no retransmission mechanism in this home au-tomation system. It is due to the reason that the retransmission should be donein the devices application layer, not from the system perspective. The packetloss in 6LoWPAN network can be described as two following reasons: channelinterference and the Watteco devices are unstable. The Watteco devices areunstable in the experiment, and sometimes need to be reboot to reconnectedto the network. And there is no retransmission mechanism shown in their ap-plication layer stack. There might be retransmission done in the network layerof the devices, but the programmer using Watteco devices are unable to awarethe state of the connection. It is better to shown in the application layer of thedevice whether it is waiting the response or their is packet loss happening. Fornow, 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 increasethe reaction time of the whole system and lead to a bad user experience. Sinceall 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 causingthe packet loss. Thus, the improvement of the 6LoWPAN devices is requiredto 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 currentCO2 ppm (parts per million) from its analog input cluster (0x00C) and thesmart plug is able to be switched on or off from its on/off cluster (0x0402) andshow the metering of active energy and reactive power from its simple meteringcluster (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 untilpeople were back for work in the afternoon. The CO2 detector functionalityworks well. However, it is worthwhile to point out that the CO2 detector is notworking 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 putonhttps://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 calculatingthe round trip time (RTT), packet loss and power consumption. It is impossibleto measure the power consumption using Wattaco devices, so the performancetests are mainly focused on RTT and packet loss. In general telecommunicationdefinition, 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 IPpackage. For the RTT measurement, it is shown in chapter 2 that since thedevices are implement 6LoWPAN protocol stack and are IP based, it is possibleto used the regular network tools. We used system ICMP Ping command toshow the system ping RTT, as well as setting timer when send a read valuecommand 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 hoplinks, both single hop 6LoWPAN network and multi-hop 6LoWPAN networkRTT are tested in stand-alone mode. For the cloud server mode, only RTT ofmulti-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 figure4, except that the cloud server is not included. All three devices are connectedto the gateway directly. In this experiment, both system ICMP ping commandand the application timer setting are used to calculate RTT. The applicationRTT timer starts from the read value command sending from the gateway andstops when the reply from the sensor is received and processed by the gatewayapplication. In figure 7, the values collected from CO2 detector are shown withthe number of the test run in x axis and the round trip time in millisecond in yaxis. The tests are run every second.

33

Figure 7: CO2 Detector RTT

From figure 7, it is obvious that both system ping RTT and applicationping RTT have the same pattern, i.e. when ping command RTT is larger, theapplication RTT is larger. This suggests that the packet transmission time isthe majority in RTT rather than the home automation system execution andprocessing time. Figure 8 gives more clear details on the same patten. It is thepart 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 smartplug have the same patten shown in figure 7 and figure 8. To save the space, onlyfinal 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 meetthe 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 DevicesCO2 Detector Smart Plug1 Smart Plug2

Min RTT(ms) 175.0 174.0 174.0Average RTT(ms) 207.6 206.9 207.0

Max RTT(ms) 622.0 650.0 635.0Sigma: 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%Packet Delivery Rate of (average RTT+3*Sigma) 97.44% 97.48% 97.44%

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. Thismeans 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 thepacket. In our experiment, a three-hop 6LoWPAN network is built. We put allthree devices in a long corridor and according to the routing table on the borderrouter, 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 testthe 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 deviceand 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 obviousthat the longer distance between the device and the gateway, the longer RTT ittakes. For the first, second and third device, the average system RTT is about184ms, 324ms and 465ms. Similar to the last subchapter, we also calculate thestandard 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 shownin table 2.

Table 2: Statistics of the System RTT of Three Hops 6LoWPAN NetworkFirst Hop Second Hop Third Hop

Min RTT(ms) 154.0 258.0 364.0Average RTT(ms) 184.1 324.5 465.3

Max RTT(ms) 846.0 1531.0 1950.0Sigma: Standard Deviation(ms) 47.0 96.9 101.0

Packet Delivery Rate of (average RTT+1*Sigma) 89.76% 91.58% 86.52%Packet Delivery Rate of (average RTT+2*Sigma) 95.13% 97.35% 97.78%Packet Delivery Rate of (average RTT+3*Sigma) 97.87% 98.58% 99.59%

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 withmulti hop 6LoWPAN devices. The total RTT is calculated from the momentwhen user sends the requesting command from user’s laptop, to the momentwhen user get the result on laptop. The request will first forward to the AmazonAWS server, and the Amazon server will forward to the home gateway. Thegateway will then send the relative command to the devices in the 6LoWPANnetwork. 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 largerthan 2 second. There are multiple reason for that. Firstly, the distance betweenthe user laptop to the cloud server and the distance between the cloud severto the home gateway is one main reason that enlarges the RTT. However, theserver is put on Ireland region, the total RTT from Sweden to Ireland is about50ms. Second, the network service provided by the internet service providermight be unstable. Third, the service provide by Amazon might be limited,since for the cost saving, only the minimal server is chosen, and the bandwidthand CPU processing ability are limited during in large traffic. More statisticscan be found in table 3.

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

First Hop Second Hop Third HopMin RTT(s) 2.247 2.354 2.463

Average RTT(s) 2.3471 2.4736 2.6124Max RTT(s) 4.307 3.8499 4.0616

Sigma: Standard Deviation(s) 0.0943 0.1187 0.1232Packet Delivery Rate of (average RTT+1*Sigma) 91.41% 91.63% 88.83%Packet Delivery Rate of (average RTT+2*Sigma) 97.43% 96.86% 97.43%Packet Delivery Rate of (average RTT+3*Sigma) 98.68% 98.17% 99.00%

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 modeand cloud server mode is supported. The result is not good enough, since theround trip time can be as high as 2 second in cloud server mode and 0.2-0.5second in stand-alone mode. The reason of these unsatisfying result might bethe problem on Wattaco devices and the low cost server.

However, from the protocol perspective, 6LoWPAN is still a quite promisingstandard in home automation. The regular user might not be able to feel thedifference between a 6LoWPAN device and a ZigBee device, but for the systemadministrator and the software programer, 6LoWPAN simplifies the work sincethere are tons on existed tools can be used.

In the future, new 6LoWPAN device along with the device’s application protocolstack will be design to provide more stability. It will be easier to integrated thedevice 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 otherfeatures of the cloud server can be studied and used in home automation systemdesign and implement.

44

45

References

[1] Gross Tobias Kays Rudiger Schaefer, Falk-Moritz. Energy consumptionof 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, ScientificAmerican. 2004.

[7] Hui j Culler D Montenegro, G. Kushalnagar N. Transmission of IPv6Packets 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. 19thInternational 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-basedhome automation system. IEEE Transactions on Consumer Electronics,(422-430), 2009.

[11] S. Ok and H. Park. Implementation of initial provisioning function forhome gateway based on open service gateway initiative platform. The 8thInternational 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 withthe 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 ona 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 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 including consumer electronics, telecom, internet, and building automation. In addition to the technical challenges about reliability, power consumption, and low complexity, the

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 the Cloud-Based Mode, to reduce the security and privacy issues by the Stand-Alone Mode, and to make the solution more friendly to both system integrators, installers, and

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 industrial value chains.

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 internet technologies can be used but they should fulfill the requirements of private cloud and public cloud respectively.

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, configuration, remote monitoring, and remote control of the field devices. More advanced services can be provided by the 3rd parties or traditionally IT service providers. The proposed

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.

• Web Interface Module: It is a simple web interface to allow the direct operation on this gateway, as long as the

Sensors & Actuators

Installer UI

Home WSAN

Installer End Consumer

Home Automation Gateway

Home IT Gateway

IT Services

End Consumer

HA SystemIntegrator

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 DomainHA Service Domain

HA Device Domain

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

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 Module and Gateway Communication Module together, and directs the data from the database to right IP address.

• 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 the IETF 6LoWPAN standard. The IETF RPL (routing protocol of the IPv6 packets over low-power and lossy

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

network) protocol is used for mesh networking. In the application layer, the ZigBee Cluster Library (ZCL) format packets are inserted as the payload of UDP packets. Besides the sensor devices, a USB 6LoWPAN Border Router is used to provide the radio connection between the Home Gateway and the sensor devices. It can be plugged on a Linux host and creates the link between standard IPv6 applications and 6LoWPAN devices. It also takes the role to setup the WSAN and in turn to allow new devices joining in.

• Home Gateway: A low cost Linus host, Raspberry Pi, is used to implement the Home 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 Communication Module and Control Module are implemented as Python program. A Python network engine is designed in the program. The Database is based on 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 WSAN devices. The Home 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 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.

• Cloud Server: The Cloud Server program runs on the Amazon AWS EC2 platform. The server image is in the Ireland Region. The service type is t2.micro which contains one virtual CPU, 1 GiB memory and 8 GB storage. The server program is based on the Python-Twisted Network Engine which has better support to asynchronous programming and network event handling. A MySQL database and a Web Interface are provided as well.

• User Interfaces: By the time this paper was written, we have not finished all the parts of UI applications on the mobile devices. A core part of the UI has been done which enables the scanning of current network to look for the Home Gateway.

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 case, the user issues some basic commands to control the 6LoWPAN devices, e.g. turning on/off a smart plug, reading the current measurement of the smart plug and the CO2 detector, and enrolling a new devices to the network. . The commands are delivered to the devices and the corresponding measurement data is correctly replied. As an example, CO2 measurements are collected over a normal working day and shown in Fig. 4.

The 2nd test case is to seek the Home Gateway in three type of network environments: 1) the Home Gateway is in a private network where the firewall allows port scan, 2) the Home Gateway is in the private network of our laboratory where the firewall doesn’t allow port scan, and 3) the Home Gateway is in 3G network. In the 1st network environment, the User Interface can find the Home Gateway successfully and the gateway IP is returned. In the 2nd and 3rd network environment, the User Interface cannot find the Home Gateway and the IP address can only be configured to the User Interface manually. This consist with the design.

B. Performance Tests

Response time is one of the primary concerns when IP-based communication is applied due to the lack of real-time mechanisms. In this work, two types of Round Trip Time (RTT) are measured:

• Ping Command RTT: it starts from the moment when the User Interface sends out a Ping command to one WSAN device, and ends at the moment when the User Interface receives a response from the device.

• Application Command RTT: it starts from the moment when the User Interface sends out an application command such as Read or Write to one WSAN device, and ends at the moment when the User Interface receives a response from the device.

Some of the data captured from an experiment in an office environment are plotted in Fig. 4 and further analyzed in Table 1. In this experiment, the Ping Command RTT and Read Command RTT of the three devices (CO2 sensor, Smart Plug 1, and Smart Plug 2) are sampled sequentially and periodically. The sampling period is 1 second and the experiment covers around 3 hours in the evening when the employees are going to leave office. Only the RTTs of the CO2 sensor are plotted since the RTTs of other two devices show the same pattern. From the plotted data in Fig. 4, it is observed the Ping

Fig. 4. CO2 measurements collected over a normal working day

Fig. 3 Implemented hardware of the Home HA Gateway, CO2 detector and

two smart plugs

Command RTT and Application Command RTT have the similar pattern over time, i.e. when Ping Command RTT is larger, the Application Command RTT is also larger. This suggests the RTT is mainly caused by the latency of packet transmission rather than the processing of data or execution of command. From the statistic of the three devices, it is observed that the three devices have similar response time which is within the range from 147ms to 650ms with an average around 207ms. If we set the bound of Maximum Acceptable RTT as (Average RTT+1*Standard Deviation), about 88% of the responses can meet this requirement. This is demoted as PDR (packet delivery rate) @1 Sigma in Table 1. Similarly, about 95% and 97% percent of the responses can be received within (Average RTT+2*Standard Deviation) and (Average RTT+3*Standard Deviation) respectively.

The above results cannot fully meet the practical requirements of HA systems according to the role of thumb which expects most (e.g. over 95%) of the responses should arrive with 150ms. This has indicated that, to reduce the network latency of 6LoWPAN is one of the important research direction in the next step. Moreover, another planned work in progress is the tests of RTTs of the Cloud-Based Mode when a Cloud Server in public cloud like Amazon is used.

VI. CONCLUSION

Cloud-Based Mode and Stand-Alone Mode are the two typical networking architecture of Wireless Home Automation

(WiHA) systems. They both have pros and cons and a hybrid mode architecture is demanded by practitioners in the HA industry. In this paper, a hybrid architecture which can support the both modes flexibility. In the proposed architecture, all IP-based WSAN technology is applied to ease the device integration and service integration. Security concerns are taken 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 helps to balance the control and benefit distribution through the value chain.

A proof-of-principle minimal system and prototype are implemented. The preliminary results of functional test confirms the feasibility of the proposed architecture but the response time of the wireless protocol is too big compared with practical HA system requirements. This is one of the important research directions in the next step.

REFERENCES [1] Zhibo Pang, “Technologies and Architectures of the Internet-of-Things

(IoT) for Health and Well-being”, PhD Thesis, Royal Institure of Technology (KTH), Stockholm, Sweden, 2013.

[2] Langhammer, N. ; Kays, R. "Performance Evaluation of Wireless Home 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] ZigBee, www.zigbee.org Online accessed on Oct 21, 2014

[4] Mulligan, Geoff Sreenan, Cormac, J. “The 6LoWPAN Architecture”, Embedded networked sensors: Proceedings of the 4th workshop, (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

[7] DECT ULE, www.ulealiance.org, Online accessed on Oct 21, 2014

[8] Low Power WiFi, www.wifi.org, Online accessed on Oct 21, 2014

[9] Bluetooth Low Energy, www.bluetooth.org, Online accessed on Oct 21, 2014

[10] The Thread Group, http://threadgroup.org Online accessed on Oct 21, 2014

[11] Introduction of Apple HomeKit, http://m.imore.com/homekit-ios-8-explained Online accessed on Oct 21, 2014

[12] ABB, Bosch, Cisco, LG joint press release on consortium for Smart Home, http://www.bosch.lt/en/lt/newsroom_17/news_16/news-detail-page_38208.php

[13] C. Gomez and J. Paradells, “Wireless home automation network: A survey of architectures and technologies”, IEEE Communications Magazine, vol.48(6,)pp.92-101, Jun. 2010

[14] Olteanu, Alexandru-Corneliu, Oprina, George-Daniel, Tapus, Nicolae, Zeisberg, Sven, “Enabling Mobile Devices for Home Automation Using ZigBee”, 2013 19th International Conference on Control Systems and Computer Science, pp. 189-195 May 2013

[15] A. R. Al-Ali and M. Al-Rousan, "Java-based home automation system", IEEE Transactions on Consumer Electronics, vol. 50, no. 2, pp. 498-504, 2004.

[16] Khusvinder Gill, Shuang-Hua Yang, Fang Yao, Xin Lu, “A ZigBee-Based Home Automation System”, IEEE Transactions on Consumer Electronics, pp.422-430, May 2009

[17] 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, pp. 1517-1520, 2006.

Time (s)0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000

RTT

(ms)

200

400

600

Ping command RTT of CO2 Detector

Time (s)0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000

RTT

(ms)

200

400

600

Read command RTT of CO2 Detector

4980 4990 5000 5010 5020 5030 5040 5050

RTT

(ms)

200

400

600

4980 4990 5000 5010 5020 5030 5040 5050

RTT

(ms)

200

400

600

Fig. 4. Round Trip Time (RTT) time of Ping Command and Read Command of the CO2 sensor

Table 1. Statistics of the Application Command RTT of three WSAN devices

CO2 sensor  Smart Plug 1  Smart Plug 2

Min RTT (ms)  175.0 174.0 174.0Average RTT (ms)  207.6 206.9 207.0Max RTT (ms)  622.0 650.0 635.0Sigma (ms)  39.0 39.5 40.6PDR@1 sigma  87.12% 88.11% 88.78%PDR@2 sigma  94.52% 94.77% 94.98%PDR@3 sigma  97.44% 97.48% 97.44%

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 automation (BA) systems are evolving towards native IP connectivity. More Industry Friendly and Native-IP Wireless Building Automation (IF-NIP WiBA) is needed to address the concerns of the entire value chain of the BA industry including the security, reliability, latency, power consumption, engineering process, and independency. In this paper, the vision, requirements, and gaps of existing efforts are reviewed first. Then a hybrid architecture which can seamless support both Cloud-Based Mode and Stand-Alone Mode is introduced based on the 6LoWPAN WSAN (wireless sensor and actuator networks) technology and verified by a prototyping minimal system. The preliminary experimental results suggest that, 1) both the WSAN and Cloud communications can meet the requirements of non-real-time application of BA systems, 2) the reliability and latency of the WSAN communications is not sufficient for soft real-time applications but it is not far away to meet such requirements by sufficient optimization in the near future, 3) the reliability of Cloud is pretty sufficient but the latency is quite far from the requirement of soft real-time applications. To optimize the latency and power consumption in WSAN, design industrial friendly engineering process, and investigate security mechanisms should be the main focus in the future.

Keywords—Fog-of-Things (FoT); Wireless Sensor and Actuator Networks (WSAN); 6LoWPAN; Native IP Connectivity (NIP); Wireless Building Automation (WiBA)

I. INTRODUCTION

Building Automation (BA) for residential buildings or homes, commercial buildings, and industrial buildings is one of the most promising application area of the Internet-of-Things (IoT) [1]. 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 and therefore the Wireless Building Automation (WiBA) has become the new design paradigm of future BA systems [2]. To bring native support of Internet Protocol (IP), the so-called Native IP (NIP), to lightweight WSAN devices is a promising direction of the evolution of communication technologies for BA systems. It can not only ease the interoperability challenges during the system integration of various devices, sub-systems, and value-added services from different suppliers, but also tear down the walls that are hindering the BA industry to benefit from the vast amount of innovations in internet domain which evolves

much faster. In practical standardization efforts, the evolution towards NIP connectivity has been clearly observed in most of the established or emerging BA communication standards, both wireless and wired, e.g. BACnet has released the BACnet/IP [3], KNX has released the KNXnet/IP [4], ZigBee has released the ZigBee IP [5], Bluetooth is developing the 6LoWPAN-over-BLE [6], and DECT ULE is developing the 6LoWPAN-over-ULE [7]. Given the standards which already have NIP connectivity such as the IEEE802.11ah Low Power WiFi [8], Thread Group [9], and the IETF IoT Suite (6LoWPAN, RPL, and CoAP) [10], the BA industry has reached a common consensus to enter the NIP era in near future even though the landscape of standardization is till fragmented.

To realize this vision of NIP-based WiBA, in addition to the technical challenges about reliability, latency, power consumption, and complexity, some important concerns from the standpoint of value chain should be addressed, e.g. “Is that a good idea to connect everything in buildings to internet or cloud? How to reduce the security and privacy risks when enjoy the benefits from IP connectivity? How to inherit the experiences, best practices and tools for engineering and commissioning? How to strengthen their roles in the existing value chain which seems potentially to be disrupted by new entrants?” In other words, the BA industry is demanding an Industry-Friendly and Native IP (IF-NIP) communication architecture which will not only meet the critical technical performances but also take care the business benefits of all the stakeholders in the value chain. However the existing efforts in this direction are insufficient due to the misinterpretation of “NIP connectivity”, or lack of friendliness to system integrators and installers, or lack of support to engineering workflow (see section II for more details).

As a work in progress, this paper intends to present some preliminary thoughts and findings towards the vision of IF-NIP WiBA systems. In particular, the concerns of BA industry are interpreted from the standpoint of the whole value chain, and gaps of existing efforts are identified. Then the vision of IF-NIP WiBA is introduced and motivated. As a natural and specific derivative of this vision, a hybrid communication architecture is proposed to support flexible combination of Cloud-Based Mode and Stand-Alone Mode. Preliminary experimental results of a prototyping minimal system based on 6LoWPAN are presented with special respects with latency and reliability. The technical feasibility of the proposed 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 consumption, and engineering process are discussed but without experimental results since they are out of the scope of this paper. This paper has figured out a visionary outline towards the next generation wireless communication architecture for future building automation systems. The industrial friendly considerations of the proposed vision and architecture can accelerate the market penetration since the major concerns of the entire industrial value chain are addressed better.

The rest of the paper is organized as follows: in Section II the vision, requirements, and gaps of existing efforts are interpreted, and the hybrid architecture is briefly introduced as well. The design and implementation of a proof-of-concept minimal system are presented in Section III. In Section IV, preliminary experimental results with respect to the latency and reliability are given. Finally the paper is concluded in Section V.

II. THE VISION, REQUIREMENTS, AND GAPS

A. Evolution towards the NIP for BA Systems

The two de facto standards of wired communication for BA systems, the BACnet and KNX, have both released the NIP edition BACnet/IP [3] and KNXnet/IP [4] respectively and achieved successful market acceptance. The evolution towards NIP is also clearly observed in the established or emerging wireless standards. First, the wireless technologies which already support NIP is trying to reduce the complexity, power consumption, and cost so as to be suitable for lightweight WSAN devices. For example, the WiFi Alliance has a plan to release a low power version IEEE802.11ah which works at sub-1GHz band dedicatedly for WSAN and IoT applications [11]. The IETF is trying to finish the application layer specification CoAP (Constrained Application Protocol) so as to provide a complete IoT Suite [12]. Second, the WSAN technologies which currently don’t support NIP are turning to NIP by embracing the 6LoWPAN (IPv6 over Low power Wireless Personal Area Networks). For example, the ZigBee Alliance has released the new generation specification of ZigBee IP [5] based on the 6LoWPAN and RPL protocols defined by IETF. The Bluetooth SIG has started to define the so-called 6LoWPAN-over-BLE together with IETF [6] based on the Bluetooth v4.1. Moreover, the DECT ULE is also working on their NIP version [7]. Given the facts, the IETF 6LoWPAN (IPv6 over Low power Wireless Personal Area Networks) and RPL (IPv6 Routing Protocol for Low power and Lossy Networks) protocols have become the de facto standards of the transformation towards NIP [10]. It is valuable to mention, the battery-free EnOcean technology also supports IP but it is not looked as NIP since the EnOcean-over-IP gateway is needed [13]. KNX-RF is not NIP either since the RF/TP or RF/IP coupler is needed to interoperate with IP network [4].

B. The Vision of IF-NIP WiBA

Given the above technical survey of the established and emerging standards and deep market survey throughout the entire value chain, we have observed that, although the BA

industry has reached the consensus towards NIP networks, the market penetration of wireless NIP technology are still not satisfactory. Besides the insufficient technical maturity of the standards, the lack of friendliness to the established value chain is pointed to be one of the root causes. In other words, an Industry-Friendly and Native IP (IF-NIP) wireless communication solution for building automation systems is not in place today. This has motivated our vision of the so-called IF-NIP WiBA. In an IF-NIP WiBA solution, the wireless communications should basically provide the same level of performances as the wired NIP technologies in terms of security, reliability, and soft real-time, and additionally provide years of battery life or even battery-free operation. At the same time, the IF-NIP WiBA solution should be compatible with the best engineering practices during system integration, commissioning, and maintenance. These requirements and gaps of existing efforts are detailed below.

C. Buildings in the Fog-of-Things

Compared with many other applications of IoT in consumer domains, the BA system is much more critical in terms of determinism, safety, security, and privacy. The term of Internet-of-Things, Intranet-of-Things, or Industrial Internet are misleading according to our experience when communicate with customers. Therefore we propose a new term of Fog-of-Things (FoT) (inspired by the concept of Fog Computing introduced by Cisco [14]) to avoid misunderstanding, emphasize crucial requirements, and be more friendly to industrial practitioners. First, it is obvious that FoT is not always to connect everything to the internet or cloud. Instead, in many cases, the networked devices can also be connected to isolated local networks or intranet. Second, the fog (the interconnected intelligence devices) is seamlessly surrounding on the ground (the physical objects in field) unlike the cloud which is far away floating over the ground. So the FoT is a better representation of the characteristics of IoT in critical applications, including the wireless connectivity, close loop control, embedded decision making, short latency, high reliability, high mobility, location awareness, and wide-spread geographical distribution. Third, professionals with industrial expertise become even more important than ever to make such FoT systems work in the field, which essentially strengthen the roles of system integrators and installers. Therefore it a more industrial friendly term.

D. Technical Requirements and Gaps

Given the requirements of future building automation systems under the context of FoT, we see after decades of efforts, the wired NIP technologies like BACnet/IP and KNXnet/IP have achieved acceptable performances of latency, reliability, and security at least for commercial buildings which are less cost-sensitive compared with residential buildings and less mission-critical compared with industrial buildings. But the wireless NIP technologies cannot yet reach the same level of performances as the wired NIP technologies [15, 16]. So the IF-NIP WiBA system must address the following technical challenges simultaneously.

• Security: Security is always the primary concern in any industrial communication system including the WiBA

system. For an extreme example, a hacker or terrorist might send a command to start all the heavy loads (e.g. air conditioners) at the same moment to trigger an accident or trip of the distribution grid. Such commands should definitely be filtered or blocked by the WiBA systems. At the same time, the privacy concerns from end consumers are also important challenge faced by the suppliers when everything is connected by wireless because attack can be performed without physical access and the loss caused by the attack can be exponentially enlarged if it is connected to internet.

• Reliability: The fundamental limit of the reliability is the interferences and distortions of radio signals are complicated and highly dynamic due to the open nature of wireless media. Moreover the reliability of RPL as the de facto routing protocol of wireless NIP today is not satisfactory under the interference of a typical home or office environment [17].

• Latency: The latency is fundamentally limited by the physical layer bandwidth. Compared with the phical layer bandwidth of wired NIP technologies which is typically 100Mbps, the bandwidth of radios used in the wireless NIP standards is too narrow e.g. up to 250Kbps for ZigBee IP and IETF IoT Suite, 1Mbps for Bluetooth LE, and 1.152Mbps for DEC ULE. According to our experimental results (see section IV), the latency of wireless NIP is too long compared with the rule-of-thumb of Soft Real-Time for non-critical control application that suggests a maximum Round Trip Time (RTT) of 150ms. In more critical cases such as the future sustainable buildings as a part of Micro Grids. Many control loops in such buildings require bounded latency and guaranteed availability to manage the power generation, storage, and consumption.

• Power Consumption: Unlike the wired NIP devices, most of the WiBA devices are expected to be battery-powered or even battery-free to fully deliver the benefits of being “really wireless”. So the above critical requirements must be met under the strict constraints of battery life e.g. no less than 3 years for non-permanently working devices. It is even desirable to have battery-free wireless NIP devices. It is challenging but the work in [18] has demonstrated the possibility of transmitting 6LoWPAN packets from a WSAN device powered by piezoelectric-based energy harvesting.

E. Non-Technical Requirements and Gaps

In nowadays BA value chain, system integrators and installers are playing essential roles to help the device manufacturers to reach end users or consumers. They integrate the devices into a usable solution by performing the complicated parameterization, configuration, installation, and commissioning according to the specific requirements of the users. Even though the do-it-yourself (DIY) market is developing quickly driven by some new entrants from out of BA domain like the Apple HomeKit [19], the role of system integrators and installers should be strengthened instead of weakened. So the IF-NIP WiBA system must be friendly to

system integrators and installers. In particular the following requirements must be met.

• Engineering Process: The BA industry has established mature engineering process and tools based on the decades of best practices. For example, the KNX Association has standardized the engineering tool software ETS and standardized device description file format. The configuration parameters are described in such files by the device manufacturer in a machine readable language. The system integrator can conveniently configure the parameters after import this file to the ETS software, and interoperability of devices from different manufacturers are also guaranteed by this means [4]. This process has been praised as one of the best practices. KNX-RF naturally supports this engineering process but unfortunately it is not NIP, The EnOcean is going to define the similar engineering tools and file formats but unfortunately it is not NIP either [20]. Actually none of the existing wireless NIP technologies can meet this requirement. Although most of them intend to provide a cloud-based autonomous service discovery and configuration solution [21], the standardization progress is unclear. And we are doubtful about the effectiveness in practice because 1) it increases the dependency of cloud infrastructure and services which is conflicting with the next requirement below, and 2) it significantly increase security vulnerabilities since the users are blind to the process.

• Independency: An essential approach to keep the health of the BA value chain is to ensure the independency of the players. On one hand, the system integrator and installer don’t want the WiBA system to rely on other infrastructure or services which are controlled by 3rd parties, e.g. the cloud service provided by the device manufactures or telecom operators. On the other hand, end users especially commercial users, don’t like to tie their WiBA systems to one more contract with a 3rd party to reduce the business complexity and security and privacy issues. Some popular solutions in DIY market cannot meet this requirement. For example, the HomeKit platform provided by Apple requires all the configuration information to be distributed by the iCloud service provided by Apple. To realize any remote control of the HomeKit-enabled WSAN devices, an iOS terminal like the iPhone, iPad, or AppleTV box is needed [19].

F. Industry Friendliness of Cloud-Based vs. Stand-Alone

Established BA system suppliers which have rooted deeply in the value chain still emphasize the so-called Stand-Alone Mode where the WiBA 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. First, it gets rid of the dependency of internet and cloud services, and therefore the issues about security and privacy can be significantly reduced. Second, the installation and configuration of such devices are more complicated for end users than Cloud-Based Mode. Thus, the role of system integrators and installers are strengthened by technical means. So it is looked as more industry-friendly.

Some solutions from new entrants have significantly simplified the configuration and commissioning efforts by the so-called Cloud-Based Mode where the WSAN devices of the WiBA 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. Traditional system integrators and installers become less important since all these work can also be done by the end users themselves, or the device manufacture if the cloud services are included in the product package, or the another service provider like telecom operators. So it is looked as not industry-friendly enough.

G. The Hybrid Architecture

Given the pros and cons of the Cloud-Based Mode and Stand-Alone Mode, the BA industry is demanding a hybrid WiBA architecture which can take the advantages of the both modes i.e. to simplify the system configuration and maintenance by the Cloud-Based Mode, to reduce the security and privacy issues by the Stand-Alone Mode, and to make the solution more friendly to both system integrators, installers, and dedicated service providers by offering flexible combination of the two modes.

The hybrid architecture for the IF-NIP-WIBA has been proposed in our previous work [22]. It can seamlessly support both Cloud-Based Mode operation, Stand-Alone Mode

operation, and flexible combination of the two basic modes. Benefited from the Cloud-Based Mode, the system integrators can choose to provide remote services for engineering, commissioning, command validation, and maintenance by 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 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 Stand-Alone Mode in a more flexible way, e.g. using the Cloud-Based Mode during commissioning to ease the engineering and configuration and using the Stand-Alone Mode after commissioning.

III. PROTOTYPES

A. Design of a Minimal System

To identify the technical requirements and verify the concepts, a minimal system of the proposed hybrid IF-NIP WiBA system architecture is designed as Fig 1. The minimal system is basically formed of four elements: an Automation 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 or the Automation Gateway directly from their UIs e.g. a smart phone or tablet, depending on user’s choice and the network connection. The 6LoWPAN technology is used in the WSAN for native support of IPv6 connectivity over low power wireless communications. More details of the minimal system is given in [22].

B. Implementation of the Prototype

A prototype of the minimal system is being implemented. Some of the hardware setup is shown in Fig. 2. Details are descripted below.

• Cloud Server: The Cloud Sever application runs in an Ubuntu 12.04 image on Amazon AWS EC2 Platform. The

UI

Data recorded in the database

Time O'clock8 10 12 14 16 18

CO

2 P

PM

400

500

600

700

800CO2 PPM in an office

Fig. 2 Implemented hardware of the minimal system including the Cloud Server, User Interface, Automation Gateway, and the WSAN devices, and the CO2 measurements collected over a normal working day in the office building

Installer

End Consumer

User Interface

Is  there a Home Gateway?

Installer UI

Consumer UI

Sensors & Actuators

WSAN

Automation 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. 1. A minimal system of the proposed hybrid IF-NIP WiBA architecture

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 Communication Module and Control Module are implemented as Python program. A Python network engine is designed in the program. The Database is based on 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 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 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 of the sensor, measuring the average latency of every sensor within the local sensor network.

• 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 the IETF 6LoWPAN standard. The IETF RPL (routing protocol of the IPv6 packets over low-power and lossy network) protocol is used for mesh networking. In the application layer, the ZigBee Cluster Library (ZCL) format packets are inserted as the payload of UDP packets. Besides the sensor devices, a USB 6LoWPAN Border Router is used to provide the radio connection between the Automation Gateway and the sensor devices. It can be plugged on a Linux host and creates the link between standard IPv6 applications and 6LoWPAN devices. It also takes the role to setup the WSAN and in turn to allow new devices joining in.

IV. PRELIMINARY RESULTS

A. Experiment Setup

As mentioned, latency and reliability are of the concerns when IP-based communication is applied due to the lack of real-time mechanisms. As shown in Fig.3, the hardware is setup in a corridor of our office building which is about 100 meters long, and the Automation Gateway is installed in the office aside. The WSAN is configured to be three hops. The Cloud Server which is deployed on the Amazon PaaS located in Ireland.

Fig. 3. Test setup in the office building

RTTGW‐h3

RTTGW‐h2

RTTUI‐h1 RTTGW‐h1

User Interface

Cloud Server

Automation Gateway

1st Hop Device

2nd Hop Device

3rd Hop Device

RTTUI‐h2

RTTUI‐h3

Fig. 4. Definition of Round Trip Time (RTT) between UI and Gateway and

between Gateway and Devices with different number of hops

B. Definition of Evaluation Criteria

In this experiment, the latency is measured by Round Trip Time (RTT). As shown in Fig. 4, two types of RTTs are defined. The RTTs are denoted by the number of hops in the WSAN. For example, the RTT between the User Interface and the 3rd hop device is denoted as RTTUI-h3. They a

• RTTUI: it starts from the moment when the User Interface sends out a command to one of the WSAN devices, and ends at the moment when the User Interface receives a response from the device. During the test, the User Interface software sends out a command to e.g. the 3rd hop Device, then the command is forwarded by the Cloud Server, Automation Gateway, 1st hop Device, and 2nd hop Device sequentially to the 3rd hop Device, then the 3rd hop Device sends out its response, then the response forwarded by the 2nd hop Device, 1st hop Device, Automation Gateway and Cloud Server sequentially back to the User Interface, finally the User Interface receives the response and records the time duration as RTTUI-hop3.

• RTTGW: it starts from the moment when the Automation Gateway sends out a command such as Read or Write to one of the WSAN device, and ends at the moment when the Automation Gateway receives a response from the device. During the test, the Automation Gateway software sends out a command to e.g. the 3rd hop Device, then the command is forwarded by the 1st hop Device, and 2nd hop Device sequentially to the 3rd hop Device, then the 3rd hop

Device sends out its response, then the response forwarded by the 2nd hop Device and 1st hop Device sequentially back to the Automation Gateway, finally the Automation Gateway receives the response and records the time duration as RTTGW-hop3.

Reliability is measured by the Round Trip Packet Error Rate (RT-PER) which is the percentage of the commands that are not responded correctly before timeout among the total commands sent during the period of test. The RT-PER are measured at the User Interface and Automation Gateway and denoted as RT-PERUI and RT-PERGW respectively.

C. Data Analysis

The test results from an experiment that lasted for about 15 hours are plotted in Fig. 5 and statistics of the data is collected in Table I. Some observations are described below.

• Latency of WSAN. RTTGW represents the latency caused by the communications within the WSAN. 1) The average RTTGW is on the order of hundreds of milliseconds, e.g. 184ms, 324ms and 465ms for 1st, 2nd hop, and 3rd hop respectively in this experiment. 2) The average RTTGW

increases proximately linearly when the number of hops increases. In experiment, the average RTTGW increases by 140ms for each hop. 3) The distribution of RTTGW is quite diverse. In experiment, the maximum RTTGW is on the order of seconds and 4 to 5 times larger than the average RTTGW.

RTTGW RTTUI

Fig. 5. Round Trip Time between Gateway and Devices (RTTGW) and between User Interface and Devices (RTTUI), and their histograms

• Latency of Cloud. The RTTUI represents the total latency caused by the communications in the WSAN and Cloud. In this experiment, it is reasonable to assume that the statistic characteristics of the WSAN and Cloud environment is stable during the period of the two commands for RTTGW and RTTUI because they are sent almost at the same moment (the error is less than sub second). So the average latency cause by the Cloud (RTTCloud) can be proximately estimated by average(RTTUI )- average(RTTGW). 1) The average RTTCloud is quite stable and not affected by the number of hops in WSAN. In this experiment, the average RTTCloud is all around 2000s for 1st hop, 2nd hop, and 3rd hop devices. 2) The distribution of RTTUI is less diverse compared with the RTTUI. In this experiment, the maximum RTTUI is always less than twice of the minimum RTTUI. 3) Occupying the major part of the total latency, the latency of Cloud is 4 to 10 times larger than the WSAN latency.

• Reliability of WSAN. The RT-PERGW represents the command failure caused by the communications within the WSAN. The RT-PERGW increases when the number of hop increases. In this experiment, we not have observed any command failure for the 1st hop device. However we are not sure about whether there is no packet loss because we are not clear if there is any re-transmission mechanism in the lower layers of the protocol implemented by the Watteco devices. The RT-PERGW increase up to 3.15% and 4.32% at the 2nd hop device and 3rd hop device respectively.

• Reliability of Cloud. The RT-PERUI represents the total command failure caused by the communications within Cloud and WSAN. Because in this experiment, the communications between the Cloud Server and User Interface and the Automation Gateway are based on TCP which has automatic retransmission and guaranteed end-to-end reliability, there is no command failure caused by the Cloud in fact. So the RT-PERUI is equal to the RT-PERGW in this experiment.

D. Performance Assessment

• Communications of WSAN. For non-real-time applications through local network, such as monitoring of status of sensors and configuration of operation parameters (e.g. schedule, work mode) of actuators by an in-home display (IHD) or smart phone, the latency and reliability of WSAN communications is acceptable. For example, in this experiment if we set the up bound of Maximum Acceptable RTT as 768ms which is the Average_RTTGW+ 3*Standard_Deviation of the furthest away 3rd hop devices, about 95.68% of the commands can receive correct responses, and 99.59% of the responses arrives within. However this cannot meet the requirement of soft real time applications such as remote control of dimmerable lights or curtains which need the latency to be imperceptible for human. According to the rule-of-thumb in practice, imperceptible latency usually is defined as >95% of the commands are responded correctly within 150ms. In this experiment, even for the nearest 1st hop device, 95.13% of the responses arrive within 278ms. But it is not far from the acceptable level.

• Communications of Cloud. The reliability of Cloud communications is pretty good for most of the applications. But the latency can only meet the requirement for non-real-time applications. It is quite far (10 time larger) from the requirements of soft real-time applications.

E. Limitations and Future Work

Due to the limitation of time, the proposed engineering process is not fully implemented on the prototype and therefore is out of the scope of this paper, but is one of the focus of the ongoing work. Another ongoing work is to evaluate and optimize the power consumption of the WSAN devices and Automation Gateway. As mentioned above, the WSAN latency cannot meet the requirement of soft real-time applications, but it is not far away, therefore we expect to solve it in the next step of our work. But since the latency of Cloud is quite far away for soft real-time applications, to optimize the latency in Cloud will not be the focus in our next step. Instead, we will look more into security issues and solutions of the Cloud communications.

V. CONCLUSION

Future building automation systems are typical practical cases of the Fog-of-Things (FoT) which represents the IoT for more critical applications. Wireless communication technologies for building automation systems are evolving towards native IP connectivity. To realize the vision of

Table I. Statistics of the Round Trip Time (RTT) and Round Trip Packet Error Rate (RT-PER)

1st Hop 2nd Hop 3rd Hop

Device Device Device

RTTUI Min(ms) 2247.2 2354.1 2463.9

Average(ms) 2347.1 2473.6 2612.4

Max(ms) 4300.7 3849.9 4061.6

σ (ms) 94.3 118.7 123.2

avg+σ (ms) 2441.4 2592.3 2735.6

avg+2σ (ms) 2535.7 2711 2858.8

avg+3σ (ms) 2630 2829.7 2982

P@avg+σ 91.41% 91.63% 88.83%

P@avg+2σ 97.43% 96.86% 97.43%

P@avg+3σ 98.68% 98.17% 99.00%

RTTGW Min(ms) 154 258 364

Average(ms) 184 324 465

Max(ms) 846 1531 1950

σ (ms) 47 96 101

avg+σ (ms) 231 420 566

avg+2σ (ms) 278 516 667

avg+3σ (ms) 325 612 768

P@avg+σ 89.76% 91.58% 86.52%

P@avg+2σ 95.13% 97.35% 97.78%

P@avg+3σ 97.87% 98.58% 99.59%

RTTCloud Average(ms) 2163.1 2149.6 2147.4

RT-PERUI % 0.00% 3.15% 4.32%

RT-PERGW % 0.00% 3.15% 4.32%

Industry Friendly and Native-IP Wireless Building Automation (IF-NIP WiBA) systems, more industry friendly wireless communication technology is needed to address the concerns of the entire value chain of the BA industry, including the security, reliability, latency, power consumption, engineering process, and independency.

In this paper, the vision, requirements, and gaps of existing efforts are reviewed first. Then a hybrid architecture which can seamless support both Cloud-Based Mode and Stand-Alone Mode is introduced based on the 6LoWPAN technology and verified by a prototyping minimal system. The preliminary experimental results suggest that, 1) both the WSAN and Cloud communications can meet the requirements of non-real-time application of BA systems, 2) the reliability and latency of the WSAN communications is not sufficient for soft real-time applications but it is not far away to meet such requirements by sufficient optimization in the near future, 3) the reliability of Cloud is pretty sufficient but the latency is quite far from the requirement of soft real-time applications.

In the next step of this work, to optimize the latency and power consumption in WSAN, implement industrial friendly engineering process, and investigate security mechanisms should be the main focus.

REFERENCES [1] Zhibo Pang, “Technologies and Architectures of the Internet-of-Things

(IoT) for Health and Well-being”, PhD Thesis, Royal Institure of Technology (KTH), Stockholm, Sweden, 2013.

[2] Langhammer, N. ; Kays, R. "Performance Evaluation of Wireless Home 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

edition of the MCC workshop on Mobile cloud computing (MCC '12), August 2012

[14] EnOcean Alliance, "EnOcean Alliance Advances Support for IP-Based Wireless Energy Harvesting Sensor and Control Technologies", 2011

[15] Konstantin Mikhaylov,Nikolaos Plevritakis and Jouni Tervonen, "Performance Analysis and Comparison of Bluetooth Low Energy with IEEE 802.15.4 and SimpliciTI", Journal of Sensor and Actuator Networks, 2013, 2, 589-613; doi:10.3390/jsan2030589

[16] Langhammer, N. ; Kays, R."Performance Evaluation of Wireless Home Automation Networks in Indoor Scenarios", Smart Grid, IEEE Transactions on,Volume:3,Issue:4,DOI: 10.1109/TSG.2012.2208770, 2012 , Page(s): 2252- 2261

[17] Dong Han ; Gnawali, O. "Performance of RPL under wireless interference", Communications Magazine, IEEE, Volume:51, Issue:12 DOI:10.1109/MCOM.2013.6685769: 2013 , Page(s): 137- 143

[18] Zimmermann, T. ; Frey, A. ; Schreiter, M. ; Seidel, J. ; Kuehne, I. "MEMS-based piezoelectric energy harvesting modules for distributed automotive tire sensors", Systems, Signals and Devices (SSD), 2012 9th International Multi-Conference on, DOI: 10.1109/SSD.2012.6198097, 2012,1-4

[19] HomeKit-Apple Developer, https://developer.apple.com/homekit, online accessed on Nov 10, 2014

[20] EnOcean Alliance, "EnOcean Alliance defines intelligent commissioning of smart buildings", July 2, 2014

[21] Cirani, S. ; Davoli, L. ; Ferrari, G. ; Leone, R. ; Medagliani, P. ; Picone, M. ; Veltri, L. "A Scalable and Self-Configuring Architecture for 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, "Preliminary Study on Wireless Home Automation Systems with Both Cloud-Based Mode and Stand-Alone Mode", to appear in the 13th IEEE Int. Conf. on Ubiquitous Computing and Communications, Dec 2014.

[23] Christopher Mims, "Forget 'the Cloud'; 'the Fog' Is Tech's Future",The Wall Street Journal, May 18, 2014