Home Automation System Design and Implementation Based on 6Lowpan

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 various functions within a house or building, such as light and plug control, energy monitoring, temperature metering, air conditioning and heating, etc. Usually, these devices are smart sensors, that are implemented with low power communication protocol like ZigBee and 6LoWPAN and only can be controlled from an Internet gateway. Nowadays, there are lots of home automation products on the market for customers. User can use application on smart phone to control the products they bought. The control command can go through a cloud-based server and be directed to the corresponding gateway, and ﬁnally reach to the sensor devices, which is referred to as ”cloud-based mode” system.

However, this single mode is not efficient under some circumstances where the Internet is not enabled or allowed. In this thesis work, a hybrid system architecture is proposed, implemented and evaluated, which include both stand-only and cloud-based mode. It offers a quick connection when user’s smart phone and the sensor gateway are in the same private network. The proposed double- mode system architecture fits user’s need and provides high reliability.

3 4 Abstrakt

Hemautomationssystem ärsmarta enheter som möjliggörolika funktioner i ett hus eller en byggnad, s˚asomkontroll av ljus och uttag, energiövervakning, tem- peraturmätning,luftkonditionering och uppvärmning,etc. Dessa enheter är vanligtvis smarta sensorer, implementerade med l˚ageffekt kommunikationspro- tokoll som ZigBee och 6LoWPAN som endast kan styras via en Internet-gateway. Numera finns det flera hemautomationprodukter p˚amarknaden. Användaren kan med sin smarta telefon styra sina produkter. Kommandot g˚arvia en molnbaserad server och vidarebefordras till motsvarande gateway, kommandot n˚arslutligen till sensoranordningarna, även kallat ”molnbaserat läge”.

Detta ”molnbaserade läge”ärinte effektiv under vissa omständigheter därin- ternetanslutning ej ärtillänglig.I detta avhandlingsarbete föresl˚as,genomförs och utvärderasen hybrid systemarkitektur som inkluderar b˚adestand-only och molnbaserade läget.Detta erbjuder en snabb anslutning näranvändarens smartphone och sensor gateway ärp˚arsamma privata nätverk. Den föreslagna systemarkitekturen passar användarensbehov och ger högtillförlitlighet.

5 6 Acknowledgement

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

7 8 Contents

1 Introduction 15 1.1 Purpose ...... 15 1.2 Research Questions and Challenges ...... 16 1.3 Structure ...... 16

2 The 6LoWPAN Protocol 17 2.1 Introduction to 6LoWPAN ...... 17 2.2 Features of 6LoWPAN ...... 17 2.2.1 Headers in 6LoWPAN ...... 17 2.3 6LoWPAN vs. ZigBee ...... 18

3 Related Study on Home Automation System 20 3.1 Diﬀerent Studies about Home Automation System ...... 20 3.2 Requirements of Home Automation System ...... 20

4 System Architecture Design 22 4.1 System Architecture ...... 22 4.2 Home Gateway ...... 22 4.3 Cloud Server ...... 23 4.4 User Interface ...... 23

5 System Implementation 25 5.1 Introduction to the System Implementation ...... 25 5.2 Watteco 6LoWPAN Devices ...... 26 5.3 Raspberry Pi Home Gateway Application ...... 27 5.3.1 Raspberry Pi ...... 27 5.3.2 Home Gateway Application ...... 27 5.4 Amazon EC2 Cloud Server ...... 28 5.5 More about the System Implemtation ...... 30 5.5.1 Long Polling Scheme ...... 30 5.5.2 Latency Measurement and Retransmission ...... 30

6 Results and Analysis 32 6.1 Functional Tests ...... 32 6.2 Performance Tests ...... 33 6.2.1 Introduction of Performance Tests ...... 33 6.2.2 Stand-alone Mode with Single Hop ...... 33 6.2.3 Stand-alone Mode with Multi-Hop ...... 36 6.2.4 Cloud Server Mode with Multi-Hop ...... 40

7 Conclusions and Future Work 44

8 Appendix 48

9 List of Figures

1 6LoWPAN Header[1] ...... 18 2 System Architecture ...... 22 3 System Modules ...... 24 4 Hardware Devices in the System Implemtation ...... 25 5 The Sample Web Interface on the Home Gateway ...... 28 6 CO2 PPM in an oﬃce ...... 32 7 CO2 Detector RTT ...... 34 8 Partial Data from CO2 Detector ...... 35 9 Histogram of 3 Devices’ RTT ...... 36 10 3 Hops 6LoWPAN Network in Oﬃce Corridor ...... 37 11 System Ping of the First Device ...... 38 12 System Ping of the Second Device ...... 39 13 System Ping of the Third Device ...... 40 14 RTT of the First Hop Device in Cloud Server Mode ...... 41 15 RTT of the Second Hop Device in Cloud Server Mode ...... 42 16 RTT of the Third Hop Device in Cloud Server Mode ...... 43

10 List of Tables

1 Statistics of the Application RTT of three Devices ...... 35 2 Statistics of the System RTT of Three Hops 6LoWPAN Network 39 3 Statistics of the RTT of Three Hops 6LoWPAN Network in Cloud Server Mode ...... 42

11 12 Acronym

6LoWPAN IPv6 and Low Power Wireless Premise Area Networks HA Home Automation IP Internet Protocol IOT Internet of Things AWS Amazon Web Service EC2 Elastic Cloud 2 PPM Parts Per Million RTT Round Trip Time HTTP HyperText Transfer Protocol DNS Domain Name System TCP Transmission Control Protocol UDP User Datagram Protocol PDR Packet Delivery Rate

13 14 1 Introduction 1.1 Purpose In a smart home automation system, various of smart sensor devices are connected with diﬀerent functionality for users. Ordinary customers can easily buy tons of diﬀerent home automation system product on the market today. Users are able to control their devices from their smart phone or tablet, at or be away from home. The smart home market is growing rapidly with the entry of num- bers of company like Honeywell, Nest, ABB, etc.

Despite of different companies’ products, from the devices’ perspective, there are several popular technologies competing for market share. The dominating communication technologies for wireless smart sensors are ZigBee, 6LoWPAN. On the contrary to the high data rate network for multimedia and Internet application, ZigBee and 6LoWPAN both use the physical layer and medium access control layer (MAC) of IEEE 802.15.4, which is designed for low data rate network for power-limit sensors and devices. The ZigBee network layer and 6LoWPAN adaption layer provides different routing mechanism to relay and transfer the packet. In [1], it is proved that 6LoWPAN is an ideal protocol to realize a uniform addressing scheme for low data rate networks as well as high data rate networks. In ZigBee IP Specification [2], the ZigBee Alliance provides its open iPv6-based standard, and the 6LoWPAN protocol is also included in ZigBee IP protocol stack.

From the system perspective, usually the company will provide a cloud-based server in their home automation system products. Users can control their devices from smart phone or tablet whenever and wherever. However, the communication to the cloud-based server is mandatory in this architecture. We believe this is not suitable for the all possible scenario. For example, the Internet connection can be down in a user home. In this architecture, user cannot control his devices, even though he is at his own home. Another example could be that in a big hotel where hundreds of smart plugs are implemented, a centralized control of this smart devices can be done within the hotel’s internal network, which the outside cloud-based server is not necessary.

What we design and implement is a double-mode system architecture, where not only the cloud-server is provided, but stand-alone mode is allowed when the user-end (smart phone, tablets, etc) and the smart devices are within the same internal network. Users can choose their preference whether cloud-based sever or stand-alone mode is suitable.

15 1.2 Research Questions and Challenges The main goal of this thesis work is to design a demo of home automation system based on the current third party devices from Watteco. The protocol stack of the Watteco devices is studied in order to implement the application on the home gateway. Meanwhile, enabling the cloud server mode requires certain mechanism to penetrate the private network firewall. To evaluate the system performance results, we separate into two categories: functional test where different functionalities of the devices are tested, and the performance tests, where the round-trip time (RTT) from different test scenarios are collected and calculated. The RTT is an important parameter in system evaluation and the RTT result will be influence by certain different variables. To build a successful system where a desirable RTT is reached, these different variables that can change the RTT need to be examined.

1.3 Structure The structure of the remaining part of the report is as follows:

Chapter 2 gives a brief introduction to the protocol 6LoWPAN. First, the architecture of 6LoWPAN protocol is shown. Second, we introduce some important features of 6LoWPAN. Third, we compare 6LoWPAN to another famous protocol in home automation ﬁeld: ZigBee.

In chapter 3 we did the literature study of home automation system. Diﬀerent home automation systems are compared. We also conclude and propose the requirements and some gaps in the current home automation system.

In chapter 4, we propose the two-mode hybrid architecture of home automation system. We separate the system into three diﬀerent modules and these three modules are shown and expained into details.

Chapter 5 gives the detailed implementation of the hybrid home automation system demo. We explain the diﬀerent technical mechanism in the Wattaco devices, home gateway application as well as the application running on Amazon EC2 cloud server.

In chapter 6 we shown the results collecting from diﬀerent test scenarios. First, we test the functionalities of the devices. Then, the single hop, multi hop RTT of the devices in stand-alone mode. For the cloud server mode, we test the multi hop case.

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

16 2 The 6LoWPAN Protocol 2.1 Introduction to 6LoWPAN 6LoWPAN is a protocol definition to enable IPv6 packets to be carried on top of low power wireless networks, specifically IEEE 802.15.4.[3] Utilizing the In- ternet Protocol (IP) in sensor network will bring us lots of advantages. First, it simplifies the connectivity model. In the past, the gateway needs to be able to translate between different application protocols of sensors and the standard Internet Protocol. Second, using IP based protocols, users can employ different tools that are already developed for configuring ,debugging networks. There is no need to develop a brand new tool set to deal with different sensor protocols. Third, since all network protocol stack are IP based, there are existed standards such as UDP, TCP, ICMP, DNS and existed services like load balancing, caching, firewall that are enable for network programmer and developers to choose and use.

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

2.2 Features of 6LoWPAN 2.2.1 Headers in 6LoWPAN There are three types of headers in 6LoWPAN standard: the Dispatch Header, the Mesh Header and the Fragmentation Header.

The Dispatch Header:

The dispatch header is 1 byte large and it is used to deﬁne the type of header to follow. If the dispatch header starts with 00, it identify that it is a non- 6LoWPAN network. If it starts with 01, it is then a 6LoWPAN network. The following 6 bit represent whether it is a IPv6 uncompressed header (000001) or IPv6 HC1 compressed encoding (000010). 111111 is reserved for the future use.

The Mesh Header:

The mesh header indicates how to encode the hop limit and the link layer source and destination of the packet. It includes two single bit fields to indicate whether the address is a short or long address, since 802.15.4 standards allows both 16 bit short addresses and standard 64 bit addresses. The next 4 bit field is the hops left field, which indicates the number of the hops left in the route.

17 The Fragmentation Header:

If the packet size is larger than the size of the 802.15.4 frame (102 byte of payload), the fragmentation and reassemble need to be supported. In the ﬁrst fragment header, the data size and the datagram tag, and the following fragment header also includes the datagram oﬀset. Although in most sensor network, the application should be aware of the underlying link layer frame size limitation, the fragmentation header is still supported in order to be compatible with standard IPv6 protocol.

Figure 1: 6LoWPAN Header[1]

2.3 6LoWPAN vs. ZigBee ZigBee is one of the most popular low-cost, low-power wireless networking standard that is widely used in smart home,smart energy, etc. The ZigBee Alliance holds the brand mark of ZigBee along with tons of ZigBee products. Same as 6LoWPAN, it also utilizes IEEE standard 802.15.4 standard. From the point of interoperability, the ZigBee devices can interoperate with other ZigBee devices. But in order to communicates with non-ZigBee network, the ZigBee devices need an application layer gateway to translate diﬀerent protocols. 6LoWPAN, on the other hand, oﬀers interoperability with other wireless 802.15.4 devices as well as other IP networks. Only simple bridge or router devices are required.

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

18 that in ZigBee network, the code size with mesh network can be as large as 32K bytes to 64K bytes, while in 6LoWPAN network, the code size with mesh network is 22K bytes.The RAM requirement to ZigBee is 8K, and for 6LoWPAN only 4K is required. The header overhead of ZigBee is 8 to 16 bytes, while the header of 6LoWPAN is 2 to 11 bytes. For the network size, 6LoWPAN support 264ˆ network size and ZigBee support up to 65K.

19 3 Related Study on Home Automation System 3.1 Diﬀerent Studies about Home Automation System Home automation system is a popular ﬁeld in academic research. [8] provides a home automation system where users can control ZigBee devices from their mobile phones and tablets. The mobile devices can either control the ZigBee devices directly, or with a USB dongle, or through the public Internet. [9] developed a Java based home automation system. All the home automation devices are connected to an embedded board physically and a Java web sever is used to provide remote access to the system. [10]proposed and implement a ZigBee home automation system where a home gateway provides interoperability between the local ZigBee and Wi-Fi network work and the Internet. [11]proposed a OSGI (Open Service Gateway Initiative), which home automation system for administration and maintenance can be accessed from service provider.

These systems have made a great contribution to the development of home automation system design. However, it is mentioned in the last chapter, all home automation system based on ZigBee required a gateway or device coordi- nator to translate the diﬀerent protocol used in the sensor’s network and outside internet network. 6LoWPAN is more conﬁguring friendly compare to ZigBee. There are studies on 6LoWPAN in home automation, too.

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

3.2 Requirements of Home Automation System In the home automation system design, there are certain technical requirements like security, reliability, latency and power consumption that need to be taken into consideration.

Security is always one of the most important issues in the system design. Con- ﬁdentiality, authentication and accessibility of the system, etc, there are tons of features in the home automation system design. Conﬁdentiality means that all the user’s data, user’s sensor’s data should be well stored and no one else but user can have the access to them. Authentication should be done in the control of the devices, from the sensor gateway directly or from the cloud server indirectly. The devices should be able to authenticated the controlling command. Accessibility to the devices and to the cloud server are both important. Jam- ming the wireless channel of the device and the denial of service to the cloud

20 server will lead to the inaccessibility to the home automation system.

Reliability of home automation device and home automation system is both important. The reliability of the device is limited to the interferences and distortions of radio signals. In a commercial home automation system product, there will be lots of users. Thus, a reliable cloud server platform is a key issue. Choosing a good cloud platform along with relative service will simplify the work a lot.

Latency is what user can experience directly. The latency in a home automation system is formed by the processing time on devices, home gateway, cloud server, as well as the signal transmission time. The bandwidth of the channel that devices are using will limit the latency. The retransmission mechanism between device and gateway or the gateway between the cloud server will make the total latency of one user behavior diﬀer a lot.

Power Consumption needs to be taken into consideration, especially for those wireless devices in the sensor network. The battery life is a strict parameter of the wireless devices. A good battery life will in turn increase the reliability and the latency of the system. The low power device might increase the transmission time, causing packet loss or even lose the connection to the gateway.

21 4 System Architecture Design 4.1 System Architecture In this section, the conceptual design of a double-mode home automation system is described. The system is outlined in Fig 2. The system is basically formed of three modules: the Home Gateway Module, the Cloud Sever Module, and the User node Module. The user can connect to cloud-base server or the home gateway directly from their smart phone or tablet, depending on user’s choice and the network connection.

Figure 2: System Architecture

4.2 Home Gateway The Home Gateway Module contains four sub-modules: cloud-sever communication module, local communication module, control model and a database. The sub-module’s explanations are described below:

Cloud-Sever Communication Module: This module is used to receive the operation command from the cloud server side and transmit the required data to the cloud sever. This module also maintain the long pulling connection to the sever, so that regular ﬁrewall policy will not be violated. A PING-PONG scheme is used to report the alive status of the home gateway to the cloud sever, combined with the regular data report from the down layer sensor devices.

22 Local Communication Module: This module allows the connection between the home gateway and user end node when they are in the same private network. This module runs a daemon thread to answer any gateways’ existence check request from the user end node within the same private network. This module also runs a simple web interface to allow the direct operation on this gateway, as long as the credential and authentication information is provided correctly.

Control Module: This module is used control the smart sensors. It receives the data and event from every sensor in the network, and transmit the operation command for cloud sever module and local communication model.

Database: Every home gateway runs a local database. It stores the credential and authentication information, and MAC address, current status of all the sensors in this network and all the required data history from user.

4.3 Cloud Server The Cloud Server Module contains four sub-modules: user communication module, gateway communication module, main module and a database. The sub- module?s explanations are described below:

User Communication Module: This module receives the request from user node and respond the request data to user. It uses our self-deﬁned interfaces for the connection from the mobile application on user node.

Gateway Communication Module: This module is used for the connection between the home gateway and the cloud server. Since it is highly possible that the home gateway is behind a ﬁrewall and it is not possible to initial the connection from the server side, the long polling scheme is used the hold up the connection. Also a PING-PONG scheme is used to report the aliveness of the home gateway.

Main Module: This is main logic module of the program on the cloud server. It combines the user communication module and gateway communication module together, and directs the right IP address from the database.

Database: This module contains user’s information, such as the IP of user’s home gateway. After getting user’s permission, it also contains the data of every sensor and history record, since the memory and storage on the home gateway is limited.

4.4 User Interface A user node module could be user’s smart phone, tablet, laptop. We provides a simple user interfaces application. From user’s side, there are three possible

23 scenarios, described as follows:

The user node and the home gateway is not in the same private network. Under this situation, the user node needs to connect to the cloud server by the application on the mobile devices.

The user node and the home gateway are in a regular private network. The application on user’s mobile devices will scan the current private network, try to build the connection to the local communication model on the home gateway. The home gateway daemon thread will listen and respond the request from the user node. It is worthwhile to point out that user can also choose to connect to the cloud server under this situation. The choice is left to user to decide.

There is another special case, where even though the user node and the home gateway are in the same private network, the scanning step in the last scenario is not permitted due to the ﬁrewall policy reason. This is quite possible in a company’s or factory’s private network. Under this situation, the administration is needed to check the home gateway’s IP ﬁrst. Then it is still possible to control the gateway and the sensors remotely by the web interfaces on the home gateway.

Figure 3: System Modules

24 5 System Implementation 5.1 Introduction to the System Implementation In this chapter, the demo system implementation is introduced based on the system modules in the last chapter. We have 6LoWPAN-supported smart home devices from Watteco, including two smart plugs and one CO2 detector, as well as a 6LoWPAN border router. We used a Raspberry Pi with a Raspbian image as the home gateway. A cloud server is put on Amazon AWS EC2 platform. This section provides a thorough discussion of the system implementation.

Figure 4: Hardware Devices in the System Implemtation

25 5.2 Watteco 6LoWPAN Devices For our two-mode system architecture home automation system implementation, we use 6LoWPAN devices from Watteco company. Two smart plugs and one CO2 detector are used in our implementation. All the devices are wireless and communicate using Radio Frequency (RF) at 868MHz (ISM band). The devices implement recent IETF networking 6LoWPAN standards for compressed IPv6 networking over low power networks (RFC4944, RFC6282, RFC 6775), IPv6 routing protocol for Low-Power and lossy network (RPL) for mesh networking (RFC6206, RFC6550).

The application layer of Watteco devices leverages the ZigBee Cluster Library (ZCL) format. Watteco provides a documents with the corresponding ZCL description, which allows us to code our program to control and communicate to the devices. More information of the application of the Wattaco devices can be found in their User Guid.[14]

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

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

Smart Plug:

In the application layer of the smart plug, two main cluster is included besides the basic cluster: On/Off Cluster and Simple Metering Cluster. The On/Off cluster allows the control and management to turn on or off the current smart plug, or simple reverse the on/off state. The simple metering cluster is supposed to allow the metering the summation of the active energy and the active power. However, after the experiment, we believe the simple metering cluster in Wat- taco smart plug is incorrectly implemented. The data retrieved from the smart plug is simple incorrect. The on/off cluster, on the other hand, is correctly implemented.

CO2 Detector:

The CO2 Detector implements the Analog Input Cluster besides the basic cluster. The data format in the frame payload is single-precision ﬂoating point. Thus, some format transform needs to be done in the gateway application to provide a decimal representation, given a better user experience. The CO2 detector allows to measure the IAQ (Indoor Air Quality) in a room. It can be used to determine the presence of a person in a room (the increase in CO2 measurement.) The device has a narrow carbon dioxide concentration

26 measurement range (in ppm) from 0 to 5000 ppm. [14]

All these three devices have their own MAC address and can be configured in to relative IPv6 address based on the configuration of the boarder router. More information for the configuration the 6LoWPAN network is shown in chapter 7.

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

5.3.2 Home Gateway Application The home gateway application is a python-based program running on the Rasp- berry Pi home gateway. But before jumping into details of the application, there are server diﬀerent IP address need to be clear for the readers. In the Raspberry Pi home gateway application, there is an IPv6 address and an IPv4 address. The home gateway application is running as a server to the 6LoWPAN devices, and as a client to the cloud server in the home automation system. Thus, the IPv6 address is used to communicates to the 6LoWPAN devices while the IPv4 address is used to communicates to the cloud server as well as working as a web engine for the local HTTP request. Python doesn’t support IPv6 socket well, so the Control Module is written in C. In the control module, it is possible to send and receive IPv6 packets from and to the 6LoWPAN devices. The data is saved in a database, which in this case is just a simple TXT ﬁle for the simplify the analysis the result.

The local communication module is an IPv4 socket listening on the port 80. In the web interface we provide, user is able to identify the states of all three devices, such as the IPv6 address, current network connection state, current average latency as well as the control to the devices such as turn on/oﬀ a smart plug, get the current measurement of the CO2 devices. When there is a ’GET’ HTTP request received, the home gateway application will reply the webpage with the current status. When there is a ’POST’ HTTP request received, the home gateway will ask the control module to do the requested work (e.g. ’switch1=on’). Meanwhile, the current status will be replied.

27 Figure 5: The Sample Web Interface on the Home Gateway

5.4 Amazon EC2 Cloud Server Our cloud server program is running on Amazon AWS EC2 platform. In order to save the cost, the type is t2.micro, which contains one virtual CPU, 1 GiB memory and 8 GB on storage is chosen as the running server instance. The cloud server application is also written in python. It listens to the port 80 of its public IP, and 8080 as the port communicating to the home gateway. In this thesis work, only minimum work is done at the server part. When an HTTP request (GET, POST) is received at the cloud server, it forwards it to the home gateway on the port 8080. When it receives the reply from the home gateway, it will forward back to the original request.

In the future, more work can be done in the cloud server module. For now, it is just a remoter server. But the real cloud server is more than just a remote server. First more features can be added. For example, show the real time measurement graph to the user, or multi home gateway supported. In this work, only one home gateway is supported, due to the reason of lack enough devices. Second, the real cloud services provide by AWS can be used in the home automation system. The AWS EC2 provides many easy-to-use services to their costumer, such as load balancing, auto scaling up/down, etc. The use of cloud service in home automation is beyond this thesis work, but can be done in the future. In this work, the cloud server application simply works as a proxy, between the user and the home automation gateway, when the user devices (cellphone, laptop, etc) is not in the same private network as the home

28 automation gateway.

29 5.5 More about the System Implemtation 5.5.1 Long Polling Scheme When the home gateway application is started at the beginning, it will initial a request to the cloud server. This is due to the reason that most gateway is in a private network, it is impossible for a cloud server with a public IP other than the private network IP to initial the connection. After the connection is built, the home gateway will send an IP packet with payload of ’PING’ to the server every 3-5min and the server will reply a ’PONG’ message in the same way. The is so-called ”PING PONG” mechanism, and it not only shows the aliveness of home gateway and the cloud server to each other, but keep the socket alive as well. In some firewall configuration, the socket alive time is limited due to the system configuration and private network firewall policy, and the socket will be closed after certain idle time. The long polling scheme keeps the socket open, and also let both server and client know that the other part is alive.

5.5.2 Latency Measurement and Retransmission As it is shown in the web interface, there is the average latency of each device. The average latency shown here is the latency between the home gateway and the devices. There are thread that keep pinging each devices every ten seconds. The home gateway application will refresh the average latency based on the system ping ICMP reply. If any device lost the connection, the connection state will be False, and the average latency will be erased and starts from 0.

In the chapter 6, it is shown that the packet maybe lost in the 6LoWPAN networks. However, there is no retransmission mechanism in this home automation system. It is due to the reason that the retransmission should be done in the devices application layer, not from the system perspective. The packet loss in 6LoWPAN network can be described as two following reasons: channel interference and the Watteco devices are unstable. The Watteco devices are unstable in the experiment, and sometimes need to be reboot to reconnected to the network. And there is no retransmission mechanism shown in their application layer stack. There might be retransmission done in the network layer of the devices, but the programmer using Watteco devices are unable to aware the state of the connection. It is better to shown in the application layer of the device whether it is waiting the response or their is packet loss happening. For now, some commands don’t have any reply at all, such as turn on/oﬀ a device. It is possible to do the retransmission in system design. For example, retrans- mit the request if there is no reply in certain time. However, this will increase the reaction time of the whole system and lead to a bad user experience. Since all the connection in the system is TCP connection except the 6LoWPAN networks, which is UDP packets sending, there is no way for the other part causing the packet loss. Thus, the improvement of the 6LoWPAN devices is required to improve the reaction time and the user experience. More system round trip

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

31 6 Results and Analysis 6.1 Functional Tests The functional tests cover all the functionalities experiment of Wattaco devices. According to the device manual, the CO2 detector is able to show the current CO2 ppm (parts per million) from its analog input cluster (0x00C) and the smart plug is able to be switched on or off from its on/off cluster (0x0402) and show the metering of active energy and reactive power from its simple metering cluster (0x0052). Figure 6 shows the data collected from the CO2 detector in an office on a

Figure 6: CO2 PPM in an oﬃce random working day. From the graph, it is obvious that since the day began, the CO2 ppm value increased from 400+ ppm to 600-700 ppm, due to the increase of the number of people in the room leading to the increase of CO2 ppm. From 12 O’clock, people were out for lunch, so the CO2 ppm decreased until people were back for work in the afternoon. The CO2 detector functionality works well. However, it is worthwhile to point out that the CO2 detector is not working stable. Sometimes it may lost connection, so the reboot is needed. The

32 way of reboot the device and rejoin the network will be on next chapter.

For the functionality tests on the two smart plug, a short video is made and put on https://www.youtube.com/watch?v=PcpE1cdhJwAlist=UU7O9NrTfCIhyXeKXOI8XbZg. The on/oﬀ cluster works ﬁne but the simple metering cluster does not work.

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

6.2.2 Stand-alone Mode with Single Hop In this stand-along Mode with single hop test, the demo is the same with ﬁgure 4, except that the cloud server is not included. All three devices are connected to the gateway directly. In this experiment, both system ICMP ping command and the application timer setting are used to calculate RTT. The application RTT timer starts from the read value command sending from the gateway and stops when the reply from the sensor is received and processed by the gateway application. In ﬁgure 7, the values collected from CO2 detector are shown with the number of the test run in x axis and the round trip time in millisecond in y axis. The tests are run every second.

33 Figure 7: CO2 Detector RTT

From ﬁgure 7, it is obvious that both system ping RTT and application ping RTT have the same pattern, i.e. when ping command RTT is larger, the application RTT is larger. This suggests that the packet transmission time is the majority in RTT rather than the home automation system execution and processing time. Figure 8 gives more clear details on the same patten. It is the part of data shown in ﬁgure 7.

34 Figure 8: Partial Data from CO2 Detector

The plot of system ping RTT and application ping RTT of the two smart plug have the same patten shown in figure 7 and figure 8. To save the space, only final histogram of RTTs collected from these 3 devices are shown here in figure 9.

From the statistic perspective, all three devices (CO2 detector, smart plug1, smart plug 2)have a similar average application ping RTT (207.6ms, 206.9ms, 207.0ms). We also calculate the standard deviation of each device (39ms, 39.5ms, 40.6ms). If we set the bound of maximum acceptable RTT as (average RTT + 1* standard deviation), about 88% of the RTT response can meet the requirement. This is demoted as PDR (packet delivery rate). Similarly, about 95% and 97% percent of response can be received within (average RTT + 2* standard deviation) and (average RTT + 3* standard deviation).

Table 1: Statistics of the Application RTT of three Devices CO2 Detector Smart Plug1 Smart Plug2 Min RTT(ms) 175.0 174.0 174.0 Average RTT(ms) 207.6 206.9 207.0 Max RTT(ms) 622.0 650.0 635.0 Sigma: Standard Deviation(ms) 39.0 39.5 40.6 Packet Delivery Rate of (average RTT+1*Sigma): 87.12% 88.11% 88.78% Packet Delivery Rate of (average RTT+2*Sigma) 94.52% 94.77% 94.98% 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. This means that it is possible that the device can be far away from the border router, as long as there are other intermediate devices helping forward and relay the packet. In our experiment, a three-hop 6LoWPAN network is built. We put all three devices in a long corridor and according to the routing table on the border router, three devices are working as the three hops network well.

36 Figure 10: 3 Hops 6LoWPAN Network in Oﬃce Corridor

Similar to the last subchapter, we also collected RTT as the system performance parameter. However, in this multi hop 6LoWPAN network, we only test the system ping RTT. The system ICMP ping command can tell us the RTT, as well as the packet loss happening if it happens. In the 3 hops 6LoWPAN network, packet loss happens in the packet transmission to the second hop device and the third hop device. More statistics can be found in table 2.

37 Figure 11: System Ping of the First Device

38 Figure 12: System Ping of the Second Device

Figure 11-13 shows the system ping RTT of all three devices. It is obvious that the longer distance between the device and the gateway, the longer RTT it takes. For the ﬁrst, second and third device, the average system RTT is about 184ms, 324ms and 465ms. Similar to the last subchapter, we also calculate the standard deviation, as well as the packet delivery rate at (average RTT + 1/2/3 * standard deviation). The above statistic along with the packet loss are shown in table 2.

Table 2: Statistics of the System RTT of Three Hops 6LoWPAN Network First Hop Second Hop Third Hop Min RTT(ms) 154.0 258.0 364.0 Average RTT(ms) 184.1 324.5 465.3 Max RTT(ms) 846.0 1531.0 1950.0 Sigma: Standard Deviation(ms) 47.0 96.9 101.0 Packet 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 with multi hop 6LoWPAN devices. The total RTT is calculated from the moment when user sends the requesting command from user’s laptop, to the moment when user get the result on laptop. The request will ﬁrst forward to the Amazon AWS server, and the Amazon server will forward to the home gateway. The gateway will then send the relative command to the devices in the 6LoWPAN network. The response will forward to user’s laptop all way back.

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

41 Figure 15: RTT of the Second Hop Device in Cloud Server Mode

Figure 14-16 shows the result. It is obvious that the response time is larger than 2 second. There are multiple reason for that. Firstly, the distance between the user laptop to the cloud server and the distance between the cloud sever to the home gateway is one main reason that enlarges the RTT. However, the server is put on Ireland region, the total RTT from Sweden to Ireland is about 50ms. Second, the network service provided by the internet service provider might be unstable. Third, the service provide by Amazon might be limited, since for the cost saving, only the minimal server is chosen, and the bandwidth and CPU processing ability are limited during in large traﬃc. More statistics can be found in table 3.

Table 3: Statistics of the RTT of Three Hops 6LoWPAN Network in Cloud Server Mode First Hop Second Hop Third Hop Min RTT(s) 2.247 2.354 2.463 Average RTT(s) 2.3471 2.4736 2.6124 Max RTT(s) 4.307 3.8499 4.0616 Sigma: Standard Deviation(s) 0.0943 0.1187 0.1232 Packet Delivery Rate of (average RTT+1*Sigma) 91.41% 91.63% 88.83% 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 mode and cloud server mode is supported. The result is not good enough, since the round trip time can be as high as 2 second in cloud server mode and 0.2-0.5 second in stand-alone mode. The reason of these unsatisfying result might be the problem on Wattaco devices and the low cost server.

However, from the protocol perspective, 6LoWPAN is still a quite promising standard in home automation. The regular user might not be able to feel the diﬀerence between a 6LoWPAN device and a ZigBee device, but for the system administrator and the software programer, 6LoWPAN simpliﬁes the work since there are tons on existed tools can be used.

In the future, new 6LoWPAN device along with the device’s application protocol stack will be design to provide more stability. It will be easier to integrated the device into the system with own protocol stack and improve the performance. Meanwhile, more work on cloud server in home automation can be studied. This project work only use the cloud server as a remote server. There are other features of the cloud server can be studied and used in home automation system design and implement.

44 45 References

[1] Gross Tobias Kays Rudiger Schaefer, Falk-Moritz. Energy consumption of 6lowpan and zigbee in home automation network. IFIP Wireless Days, (1-3), 2013. [2] Zigbee ip specification. http://www.zigbee.org/Specifications/ZigBeeIP/Overview.aspx. [3] Geoff Mulligan. The 6lowpan architecture. Embedded networked sensors: Proceedings of the 4th workshop, (EmNets ’07), (78-82), 2007. [4] Carsten Borman Zach Shelby. 6LoWPAN: The Wireless Embedded Internet (Wiley Series on Communications Networking and Distributed Systems). 2010. [5] Hui J Culler, D. 6LoWPAN Tutorial,Tiny OS Technology Exchange. 2007. [6] Kerkorian R. Cohen D. Gershenfeld, N. The Internet of Things, Scientific American. 2004. [7] Hui j Culler D Montenegro, G. Kushalnagar N. Transmission of IPv6 Packets over IEEE 802.15.4 Networks. [8] Oprina George-Daniel Tapus Nicolae Zeisberg Sven Olteanu, Alexandru- Corneliu. Enabling mobile devices for home automation using zigbee. 19th International Conference on Control Systems and Computer Science, (189- 195), 2013. [9] A. R. Al-Ali and M. Al-Rousan. Java-based home automation system. IEEE Transactions on Consumer Electronics, 50(498-504), 2004. [10] Fang Yao Xin Lu Khusvinder Gill, Shuang-Hua Yang. A zigbee-based home automation system. IEEE Transactions on Consumer Electronics, (422-430), 2009. [11] S. Ok and H. Park. Implementation of initial provisioning function for home gateway based on open service gateway initiative platform. The 8th International Conference on Advanced Communication Technology, (1517- 1520), 2006. [12] Novi Sad Serbia ; Mrazovac B. ; Teslic N. ; Papp I. Bjelica, M.Z. ; RT- RK Comput. Based Syst. Cloud-enabled home automation gateway with the support for upnp over ipv4/ipv6 and 6lowpan. Consumer Electronics (ICCE), 2012 IEEE International Conference, (520-521), 2012. [13] Jafar Saniie Thomas Gonnot. User defined interactions between devices on a 6lowpan network for home automation. Technology Management Confer- ence (ITMC), 2014 IEEE International, (1-4), 2014. [14] Wattaco. IP Wireless Sensors User Guide, Specifications and Performance, Control and Management Interfaces.

46 47 8 Appendix

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

Zhibo Pang1, Yuxin Cheng2, Morgan E. Johansson1, Gargi Bag1 1, Corporate Research, ABB AB, Västerås, Sweden 2, ICT School, Royal Institute of Technology (KTH), Stockholm, Sweden {pang.zhibo|morgan.e.johansson|gargi.bag}@se.abb.com, [email protected]

Abstract—As the Smart Home segment is an intersection of communication architecture is also required to support both numerous industries including consumer electronics, telecom, Cloud-Based Mode and Stand-Alone Mode. internet, and building automation, a Home Automation (HA) system requires flexible wireless communication architecture to In particular, in the Cloud-Based Mode, the WSAN devices not only take the advantages of wireless technologies such as of the WiHA system are all connected to a kind of server in the reduced cost of installation and maintenance and improved user cloud and users can monitor and control the devices through experiences but also fulfill the concerns of various industrial the internet during configuration as well as usage. In the Stand- stakeholders. From this point-of-view, neither the pure Cloud- Alone Mode, the devices are interconnected to each other Based nor the Stand-Alone architecture is sufficient. In this directly or through a kind of local gateway, and users can paper, an IP-based hybrid architecture is presented which can monitor and control the devices locally without any support flexible combination of Could-Based Mode and Stand- involvement of internet or cloud server. The Cloud-Based Alone Mode. Preliminary prototyping based on the 6LoWPAN Mode can reduce the effort for end consumer to install, and experimental evaluation of performances have indicated the configure and manage the WiHA devices since all these work technical feasibility as well as future directions of improvement. are done either by the device manufacture if the cloud services are also included in the product package, or by the a dedicated Keywords—Internet-of-Things (IoT); Wireless Sensor and service provider. It is usually preferred in the do-it-yourself Actuator Networks (WSAN); 6LoWPAN; Cloud-Based Mode, (DIY) market driven by new entrains from out of HA industry Stand-Alone Mode; Home Automation (HA) like the Google Nest[10] and Apple HomeKit [11] and telecom or broadcast service providers. However it is not sufficiently I. INTRODUCTION friendly to the system integrators and installers which play As digital representation of real world, the Internet-of- essential roles in the value chain of HA industry. Moreover, the Things (IoT) integrates all kinds of sensing, control, security and privacy concerns from end consumers are also identification, communication, networking, and informatics important challenge faced by the suppliers. In contrast to the devices and systems, and seamlessly connects all the people Cloud-Based Mode, the Stand-Alone Mode gets rid of the and things upon interests, so that anybody, at any time and any dependency of internet and cloud services. By doing this with place, through any device and media, can more efficiently proper cyber security techniques, the issues about security and access the information of any object and any service [1]. The privacy can be significantly reduced. As an expense, the Home Automation (HA) is one of the most promising installation and configuration of WiHA devices are more application area of the IoT. Thanks to the reduced cost of complicated for end consumers compared to usual consumer installation and maintenance and improved user experiences, electronic devices and the WiHA devices in Cloud-Based Wireless Sensor and Actuator Network (WSAN) technologies Mode. In practice, the installation and configuration work is are being actively applied or developed [2]. Some of these usually done by professionals of system integrator or installers. technologies that have gained much attention include the Therefore the Stand-Alone Mode is looked as friendlier to ZigBee Pro [3], ZigBee IP [3], IETF 6LoWPAN (IPv6 over system integrators and installers since they can keep their Low power Wireless Personal Area Networks) [4], EnOcean essential roles in the value chain, and it is usually preferred by [5], KNX-RF[6], DECT ULE [7], Low Power WiFi [8], the established HA system suppliers which have rooted deeply Bluetooth Low Energy [9], and Thread [10]. The designers of in the HA value chain [12]. Wireless Home Automation (WiHA) systems have to manage Given the pros and cons of the Cloud-Based Mode and the challenges caused by the diverse requirements from Stand-Alone Mode, the HA industry is demanding a hybrid different stakeholders in the value chain because the Smart architecture which can take the advantages of the both modes Home segment is an intersection of numerous industries i.e. to simplify the system configuration and maintenance by including consumer electronics, telecom, internet, and building the Cloud-Based Mode, to reduce the security and privacy automation. In addition to the technical challenges about issues by the Stand-Alone Mode, and to make the solution reliability, power consumption, and low complexity, the more friendly to both system integrators, installers, and dedicated service providers by offering flexible combination of III. SYSTEM ARCHITECTURE the two modes. However, the existing research on this is insufficient from the point-of-view of HA industry (see section A. Overview II). The proposed hybrid WiHA communication architecture In this paper, an IP-based hybrid architecture for WiHA that can operate both in Cloud-Based Mode and in Stand- systems which can seamlessly integrate both the Cloud-Based Alone Mode is illustrated in Fig. 1. The key elements of the Mode and Stand-Alone Mode with minimized cost to switch Smart Home system including the WiHA system are separated between the two modes. A prototype is implemented based on into three domains as follows. the 6LoWPAN which brings native IP compatibility to low  HA Device Domain: It comprises all the field devices of power and low cost wireless WiHA devices. A scalable the WiHA system including the sensors and actuators, gateway architecture which can be deployed both on low cost WSAN network devices (e.g. routers, bridges), home embedded devices in the homes or on high performance servers automation gateway, and Consumer User Interface (UI) in the cloud is designed. A prototype system is implemented (e.g. smart phone with apps). The devices in the HA and experimental tests are carried out with a focus on the Device Domain are connected by short range wireless timing performances. The preliminary results have confirmed communications through the WSAN. In this domain, end the technical feasibility of the proposed architecture but the consumers can interact with the WiHA directly through round trip time, typically 207ms for 1 hop WSAN, is still too the sensors and actuators or through the Consumer UI, long compared with the practical HA system requirements. which is called the Stand-Alone Mode. This will be an important direction of future research.  HA Service Domain: It comprises the backbone system of The rest of the paper is organized as follows: in Section II the HA System Integrator, private cloud infrastructure, and related works are reviewed from system architecture Installer UI (e.g. smart phone with apps). The HA Service perspective. In Section III the proposed hybrid system Domain is interconnected by private cloud which is architecture is introduced. The design of a minimal system and intensively safeguarded by firewalls. In this domain, implementation of a prototype are presented in Section IV. In installers can interact with the WiHA devices in field Section V, preliminary experimental results with respect to the through the Installer UI. response time are given. Finally the paper is concluded in Section VI.  IT Service Domain: It comprises the backbone system of various IT services (e.g. energy analytics, home service, II. RELATED WORK utility billing, and entertainment), public cloud infrastructure, in-home IT gateway, and Consumer UI. There exist a significant research work done with respect The IT Service Domain is interconnected by public cloud the communication architecture of WiHA systems [13]. For through wired or wireless wide area network technologies example, Olteanu et al. provided a home automation system such as 3G/4G, FTTH, Ethernet, HomePlug, etc. In this where users can control ZigBee devices from their mobile domain, end consumers can only interact with the WiHA phones and tablets [14]. The mobile devices can either control indirectly through the cloud, which is called the Cloud- the ZigBee devices directly, or with a USB dongle, or through Based Mode. the public Internet. Al-Ali and Al-Rousan developed a Java based home automation system [15]. All the home automation B. Domain-Based Access Control devices are connected to an embedded board physically and a Java web server is used to provide remote access to the system. In the proposed architecture, different domain has different Gill et al. proposed and implemented a ZigBee home level of vulnerability. In the IT Service Domain which is the automation system where a home gateway provides most vulnerable domain of the WiHA system, hackers can interoperability between the local ZigBee and Wi-Fi network attack the WiHA system remotely from any place of the world work and the Internet [16]. Ok and Park proposed a OSGI in theory. So the it has to be isolated as much as possible and (Open Service Gateway Initiative), which home automation no direct control flow is allowed from the IT Service Domain system for administration and maintenance can be accessed and the HA Device Domain. from service provider [17]. These systems have made a great contribution to the development of home automation system C. Domain-Based Network Integration design. However, the authors have observed a gap between The classification of domains makes it convenient to decide industrial practice and academic work. First, the architecture the networking technologies of each domain and in between prosed in the literatures is lack of harmonization of Cloud- two domains. In the HA Device Domain, to increase the cost of Based Mode and Stand-Alone Mode, i.e. they either focus on direct invasion to the sensors of actuators, short range wireless Cloud-Based Mode or focus on Stand-Alone Mode. How to communication technologies with sufficient end-to-end combine the two modes in a single solution is not presented. security is needed for the Home WSAN. Some of the Second, the concerns of the HA system integrators and promising candidates are ZigBee Home Automation, ZigBee installers are not considered sufficiently which implies the IP, and IETF IoT Stack (6LoWPAN, RPL, and CoAP). In the need of re-thinking this question from the point-of-view of HA Service Domain and IT Service Domain, conventional industrial value chains. internet technologies can be used but they should fulfill the requirements of private cloud and public cloud respectively. architecture helps to balance the control and distribution of HA Service Domain IT Service Domain benefits through the value chain. For example, an energy HA System Integrator IT Services efficiency company can provide energy analytic service by collecting the power consumption pattern, plan of activities, and real-time price of utilities and heat, and reduce the energy cost by optimizing the schedule of loads. To do this, the energy Public Cloud analytic service provider should get the authentication from the End HA System Integrator and install it into the Home IT Gateway Consumer UI Consumer Home IT accordingly. Otherwise, it is not allowed to control the field Gateway devices even though it might be able to read the load data from Private Cloud the field.

IV. DESING OF A MINIMAL SYSTEM HA Device Domain Home Automation A. General Requirements and Challenges Gateway To identify the technical requirements and verify the

Installer End concepts, a minimal system of the proposed hybrid WiHA Installer UI Consumer UI Consumer system architecture is designed as Fig 2. The minimal system is basically formed of three modules: a Home Gateway, a Cloud Home WSAN Wide Area Network Server, User Interface (UI), and a series of sensors and Home IT Network actuators connected through Home WSAN. The users (end Home Wireless Network consumers or installers) can connect to the Cloud Server or the Human Machine Interaction Home Gateway directly from their UIs e.g. a smart phone or Control Flow of Cloud‐ Based Mode (Consumer) tablet, depending on user’s choice and the network connection. End To accomplish the propose architecture, the Home WSAN is Sensors & Actuators Consumer required to provide IP connectivity over low power and low Fig. 1. The proposed hybrid WiHA architecture and example control flows of cost short range wireless communication. The 6LoWPAN Cloud-Based Mode technology is selected due to its native support of IPv6 connectivity and low power wireless capabilities. Between the Home Automation Gateway and the Home IT B. Home Gateway Gateway, secured home IT network should be used such as WiFi and Ethernet with end-to-end security. In the minimal system, the Home Gateway represents the Home Automation Gateway and the Home IT Gateway of the D. Operations of Stand-Alone Mode proposed hybrid architecture. It comprises five modules: the server communication module, local communication module, In the Stand-Alone Mode, the Consumer UI joints the control model and database. Home WSAN under the supervision of the Home Automation Gateway. Direct two-way communications between the • Server Communication Module: This module is used to Consumer UI and sensors and actuators are possible in the so- receive the operation command from the Cloud Server and called peer-to-peer mode. Or otherwise, the communications transmit the required data to the Cloud Server. It also between Consumer UI and sensors and actuators are handed maintains a long polling connection to the cloud server, i.e. through the Home Automation Gateway in the so-called the Home Gateway periodically sends requests of data to centralized mode. the Cloud Server. In case the Home Gateway is in a private network guarded by firewalls, this request will ask the E. Operations of Cloud-Based Mode firewall to open the “door” for the target Cloud Server for a certain period (e.g. minutes) to allow the Cloud Server to The end consumers can access the sensor and actuators send data to the Home Gateway. Period polling requests remotely e.g. when they are travelling or at office. The will keep the door open which makes it possible that the monitoring of the status is less critical and allowed to go from Cloud Server can access the WSAN devices timely the Home Automation Gateway, through the Home IT whenever the users want since the “door” is already Gateway and the public cloud directly to the Consumer UI. “opened”. However the control flow is more crucial and not allowed to simply go through the public cloud. • Local Communication Module: This module manages the connection between the Home Automation Gateway and F. Cross-Domain Service Integration User Interface when they are in the same private network. In industrial practice, the HA System Integrator can choose This module runs a daemon thread to response to any to provide only basic HA services like field installation, requests from the User Interface e.g. to check the existence configuration, remote monitoring, and remote control of the of the Home Gateway. field devices. More advanced services can be provided by the • Web Interface Module: It is a simple web interface to allow 3rd parties or traditionally IT service providers. The proposed the direct operation on this gateway, as long as the • User Communication Module: It receives the request from Cloud Server UIs and transmits respond data to users. It uses customized Cloud Main Module interface to secure the connection from the mobile Database applications on UIs. Gateway Mobile Communication Communication • Gateway Communication Module: It is used for the Module Module connection between the Home Gateway and the Cloud Server. In case the Home Gateway is behind a firewall in a private network, the transactions between the Cloud Server User Installer Interface Home Gateway can only be imitated by the Home Gateway UI by the aforementioned long polling scheme. Installer Is there a Private or Public Home Gateway? • Database: It stores users’ information such as the IP Network Consumer address of every user’s home gateway. If authorized by the UI End user, it is also possible to store the data and history record Long Consumer Polling of every sensor and actuator. But the amount of history data is limited because 1) the memory and storage on the home Home Gateway gateway is limited, and 2) this can reduce the potential loss Local Server caused by any security issue. Communication Communication Module Module D. User Interface Web Interface Module A User Interface could be user’s smart phone, tablet, or Local Database laptop running the Consumer UI of Installer UI applications. Control Module From user’s point-of-view, there are three possible scenarios as described below:

Home WSAN • Scenario 1: The User Interface and the Home Gateway are not in the same private network. Under this situation, the User Interface needs to connect to the Cloud Server by the application on the mobile devices. • Scenario 2: The User Interface and the Home Gateway are in a regular private network. The application on user’s Sensors & Actuators mobile devices will scan the current private network, try to Fig. 2. A minimal system of the proposed hybrid WiHA architecture build the connection to the Local Communication Module in the Home Gateway. It is worthwhile to point out that users can also choose to connect to the Cloud Server under credential and authentication information is provided this situation upon their interests. The choice is left to user correctly. to decide. • Control Module: This module is used to control the sensors • Scenario 3: This is a special case where even though the and actuators. It receives the data and event from every User Interface and the Home Gateway are in the same sensor in the network, and transmit the operation command private network, the scanning operation in the Scenario 2 is to the actuators from the Cloud Server and the Local not permitted due to the firewall policy. This is quite Communication Module. common in the enterprise private network. Under this • Database: Every Home Automation Gateway runs a local situation, the administration is needed to check the Home database. It stores the credential and authentication Gateway’s IP first, then it is still possible to control the information, MAC addresses, current status of all the Home Gateway and the sensors and actuators remotely sensors in this network, and the history data required from through the Web Interface on the Home Gateway. users. E. Implementation of a Prototype C. Cloud Server As a part of the work in progress, a prototype of the In the minimal system, the Cloud Server represents the minimal system is being implemented. Some of the hardware servers of the HA System Integrators and IT service providers setup is shown in Fig. 3. Details are descripted below. of the proposed hybrid architecture. It comprises four modules: • Home WSAN Devices: The 6LoWPAN devices from the User Communication Module, Gateway Communication Watteco NKE Electronics are selected to implement the Module, Main Module and Database. WSAN devices. Two smart plugs and one CO2 detector are • Main Module: It is the main logic of the program on the used in the prototype system. All the devices are operates at Cloud Server. It combines the User Communication 868MHz ISM band. The IPv6 adaptation layer is based on Module and Gateway Communication Module together, the IETF 6LoWPAN standard. The IETF RPL (routing and directs the data from the database to right IP address. protocol of the IPv6 packets over low-power and lossy Fig. 4. CO2 measurements collected over a normal working day

V. PRELIMINARY RESULTS

A. Functional Tests Functional tests have been carried out by two test cases. st The 1 test case is regular access to the WSAN devices. In this Fig. 3 Implemented hardware of the Home HA Gateway, CO2 detector and case, the user issues some basic commands to control the two smart plugs 6LoWPAN devices, e.g. turning on/off a smart plug, reading the current measurement of the smart plug and the CO2 network) protocol is used for mesh networking. In the detector, and enrolling a new devices to the network. . The application layer, the ZigBee Cluster Library (ZCL) format commands are delivered to the devices and the corresponding packets are inserted as the payload of UDP packets. Besides measurement data is correctly replied. As an example, CO2 the sensor devices, a USB 6LoWPAN Border Router is measurements are collected over a normal working day and used to provide the radio connection between the Home shown in Fig. 4. Gateway and the sensor devices. It can be plugged on a nd Linux host and creates the link between standard IPv6 The 2 test case is to seek the Home Gateway in three type applications and 6LoWPAN devices. It also takes the role of network environments: 1) the Home Gateway is in a private to setup the WSAN and in turn to allow new devices network where the firewall allows port scan, 2) the Home joining in. Gateway is in the private network of our laboratory where the firewall doesn’t allow port scan, and 3) the Home Gateway is • Home Gateway: A low cost Linus host, Raspberry Pi, is in 3G network. In the 1st network environment, the User used to implement the Home Gateway. It has 512 MB of Interface can find the Home Gateway successfully and the RAM, two USB ports and a 100Mb Ethernet port. The gateway IP is returned. In the 2nd and 3rd network environment, Raspbian Image is used as the gateway operating system. the User Interface cannot find the Home Gateway and the IP The Server Communication Module, Local Communication address can only be configured to the User Interface manually. Module and Control Module are implemented as Python This consist with the design. program. A Python network engine is designed in the program. The Database is based on SQLite database B. Performance Tests running on the Raspberry Pi. A simple Web Interfaces is Response time is one of the primary concerns when IP- also provided. After giving the right user name and based communication is applied due to the lack of real-time password, users can have a direct control to the WSAN mechanisms. In this work, two types of Round Trip Time devices. The Home Gateway application integrates IPv4 (RTT) are measured: socket and IPv6 socket harmoniously. The IPv4 socket manages the communication with the Could Server, as well • Ping Command RTT: it starts from the moment when the as responds to the HTTP request from the Web Interface. User Interface sends out a Ping command to one WSAN The IPv6 socket manages the connection to the USB device, and ends at the moment when the User Interface 6LoWPAN Border Router not only to control the devices receives a response from the device. within the WSAN but also to enroll a new devices to the network. • Application Command RTT: it starts from the moment when the User Interface sends out an application command • Cloud Server: The Cloud Server program runs on the such as Read or Write to one WSAN device, and ends at the Amazon AWS EC2 platform. The server image is in the moment when the User Interface receives a response from Ireland Region. The service type is t2.micro which contains the device. one virtual CPU, 1 GiB memory and 8 GB storage. The server program is based on the Python-Twisted Network Some of the data captured from an experiment in an office Engine which has better support to asynchronous environment are plotted in Fig. 4 and further analyzed in Table programming and network event handling. A MySQL 1. In this experiment, the Ping Command RTT and Read database and a Web Interface are provided as well. Command RTT of the three devices (CO2 sensor, Smart Plug 1, and Smart Plug 2) are sampled sequentially and periodically. • User Interfaces: By the time this paper was written, we The sampling period is 1 second and the experiment covers have not finished all the parts of UI applications on the around 3 hours in the evening when the employees are going to mobile devices. A core part of the UI has been done which leave office. Only the RTTs of the CO2 sensor are plotted enables the scanning of current network to look for the since the RTTs of other two devices show the same pattern. Home Gateway. From the plotted data in Fig. 4, it is observed the Ping (WiHA) systems. They both have pros and cons and a hybrid 600 mode architecture is demanded by practitioners in the HA 400

RTT200 (ms) industry. In this paper, a hybrid architecture which can support 4980 4990 5000 5010 5020 5030 5040 5050 the both modes flexibility. In the proposed architecture, all IP- based WSAN technology is applied to ease the device 600 400 integration and service integration. Security concerns are taken

RTT200 (ms) 4980 4990 5000 5010 5020 5030 5040 5050 into account by forbidding the control flow that directly comes from public cloud. The HA System Integrator should be involved to accomplish more advanced HA services which Ping command RTT of CO2 Detector helps to balance the control and benefit distribution through the 60 0 value chain. 40 0

RTT(ms) 20 0 A proof-of-principle minimal system and prototype are 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 Time (s) implemented. The preliminary results of functional test Read command RTT of CO2 Detector confirms the feasibility of the proposed architecture but the 60 0 response time of the wireless protocol is too big compared with 40 0 practical HA system requirements. This is one of the important

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

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

Cloud Main Module Database

Gateway Mobile UI Communication Communication Module Module

CO2 PPM in an office User 800 Installer 700 Interface UI 600

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

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

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