Experimental Study of Thread Mesh Network for Wireless Building Automation Systems

Home , KNX (standard), Matter (standard), Sensor node, Smart meter, TinyOS, WirelessHART

EXAMENSARBETE INOM ELEKTROTEKNIK, AVANCERAD NIVÅ, 30 HP STOCKHOLM, SVERIGE 2016

DAPENG LAN

KTH SKOLAN FÖR ELEKTRO- OCH SYSTEMTEKNIK

KTH ROYAL INSTITUTE OF TECHNOLOGY Abstract

Master of Science

Experimental Study of Thread Mesh Network for Wireless Building Automation Systems

by Dapeng LAN

Wireless sensor network technologies have gained signiﬁcant popularity in home automation due to their scalability, system mobility, wireless connectivity, inexpensive and easy commissioning. Thread, a new wireless protocol aiming for home automation, is proposed by Google Nest and standardized by Thread Group. This thesis presents a thorough experimental evaluation of Thread wireless protocol with the hardware platform from NXP. The test plan, implementation, and analysis of the experiments is discussed in details, including signal coverage, unicast and multicast latency, reliability, and availability. Furthermore, a system level model considering the delay in different layers for the latency of Thread mesh network is presented, and validated by the experimental results. Finally, a friendly tool was developed for installers to estimate the latency of Thread mesh network. ! ! ! ! ! ! ! ! ! Sammanfattning) ! Trådlösa) sensornätverk) har) fått) betydande) popularitet) för) hemautomation) på) grund) av) deras) skalbarhet,) systemmobilitet,) trådlösa) konnektivitet,) låga) prisnivå) och) enkla) implementation.) Thread,)ett)nytt)trådlöst)protokoll)avsett)för)hemautomation,)är) föreslaget)av)Google)Nest)och)standardiserat)av)Thread)Group.) ) Denna) uppsats) presenterar) en) ingående) experimentell) utvärdering) av) det) trådlösa) ThreadAprotokollet) med) en) hårdvaruplattform)från)NXP.)Testplanen,)implementationen)och) analysen)av)experimenten)diskuteras)i)detalj)innehållandes)signal) täckning,) unicast) och) multicast) latens) samt) tillgänglighet.) Dessutom) presenteras) en) modell) på) systemnivå) som) tar) fördröjningar) i) olika) lager) för) latensen) i) ThreadAnätverket) i) hänseende,) vilken) även) är) validerad) genom) testresultaten.) Slutligen,) utvecklades) ett) användarvänligt) verktyg) för) installationspersonal) för) att) estimera) latensen) i) ThreadAmeshA nätverket.))) ) iii

Acknowledgements

First and foremost, I would like to thank my research supervisor in ABB corporate research, Zhibo Pang, for his constant guidance, enthusi- asm, knowledge and offering the opportunity to investigate the state-of-art WSN protocol - Thread. Also I would like to thank my co-supervisor, Gargi Bag, for her patience toward solving my confusions and her kindly encour- agement. This paper would never be accomplished without their valuable assistance and dedicated involvement. Furthermore, I would like to thank my examiner, Carlo Fischione. Besides, I would like to thank my research group members Eva Azoidou and Yu Liu. They gave me support during my research period and helped me spend pleasurable life in ABB. It is difﬁcult to mention all friends I have met in ABB and KTH, whom I have learnt a lot of things from and offered me unforgettable experience. Thanks to all of them. Finally, I would like to thank my parents for giving me any kinds of support substantially and spiritually throughout my studying life.

Contents

Abstract i

Acknowledgements iii

1 Introduction 1 1.1 Background ...... 1 1.2 Problem Statement ...... 2 1.3 Methodology ...... 2 1.4 Contribution of the Thesis ...... 3 1.5 Outline ...... 3

2 Related work in Wireless Sensor Networks 5 2.1 From Non-IP to Native IP ...... 5 2.2 Overview of the IEEE 802.15.4 standard ...... 5 2.2.1 Non-beacon enabled IEEE 802.15.4 CSMA/CA .... 6 2.3 IETF IoT stacks ...... 7 2.3.1 6LoWPAN ...... 7 2.3.2 RPL ...... 8 2.3.3 CoAP ...... 9 2.4 Overview of Thread protocol ...... 9 2.4.1 Protocol stacks ...... 9 2.4.2 Device types ...... 10 2.4.3 Multicast Protocol for Low power and lossy networks (MPL) ...... 11 2.4.4 Comparison with other protocols ...... 11 2.5 Other protocols ...... 12 2.5.1 Zigbee ...... 12 2.5.2 WirelessHART and ISA100 ...... 12

3 Test plan 15 3.1 Signal Coverage ...... 15 3.2 Unicast latency and reliability ...... 16 3.3 Multicast latency and reliability ...... 17 3.4 Availability ...... 18

4 Experimental Setup 19 4.1 Test platform ...... 19 4.2 Signal Coverage Setup ...... 20 4.3 Unicast Latency and Reliability Setup ...... 20 4.4 Multicast Latency and Reliability Setup ...... 23 4.5 Availability Test Setup ...... 24 vi

5 Result Analysis 25 5.1 Signal Coverage ...... 25 5.2 Unicast and Reliability ...... 26 5.3 Multicast and Reliability ...... 29 5.4 Availability ...... 30

6 Modeling and Validation of Latency in the Thread Mesh Network 31 6.1 System model of latency of multihop Thread mesh network 31 6.2 Numerical results and experimental validation ...... 33 6.2.1 Statistical probability distribution of MAC service time 34 6.2.2 Latency related to hardware and software implementation ...... 34 6.2.3 Experimental validation of Thread mesh network .. 35 6.2.4 Software tool to estimate the latency of Thread mesh network ...... 35

7 Conclusion and Future work 39 7.1 Conclusions of the work ...... 39 7.2 Future work ...... 40

Bibliography 41 vii

List of Figures

1.1 The portal of research methods and methodologies(Håkansson, 2013) ...... 3

2.1 The unslotted IEEE 802.15.4 CSMA/CA channel access mechanism ...... 7 2.2 IETF LLN protocol stack ...... 8 2.3 Thread protocol stacks...... 10 2.4 Thread device types(Threadgroup ofﬁcial website) ...... 10

3.1 Deﬁnition of round trip time ...... 16

4.1 Hardware platform - FRDM-KW24D512 ...... 19 4.2 Signal coverage test setup ...... 20 4.3 Thread mesh network topology ...... 20 4.4 Communication between laptop and border router ...... 21 4.5 nodes placement in the building ...... 22 4.6 Deployment of Nodes in the building for multicast test ... 23

5.1 Latency result of 6 hops for 4 test cases ...... 26 5.2 Packet delivery ratio with the deadline 50ms, 100ms, 150ms, 200ms ...... 27 5.3 Comparison between 4 cases with respect to different hops . 28 5.4 CDF of TCC in multicast latency test ...... 29 5.5 Availability result of Thread mesh network with 38 nodes .. 30

6.1 System model of the latency of Thread mesh network .... 31 6.2 latency of different layer in Thread network ...... 31 6.3 MAC service time distribution. (a) shows the relationship between the probability distributions and the nodes numbers N with = 0.2. (b) shows the relationship between the the probability distributions and with N = 10...... 33 6.4 experimental test of PHY layer latency (A) and IPS layer latency (B) ...... 33 6.5 Unicast latency results for 6-hop mesh network of Thread: (A) case 1 (B) case 4 ...... 37 6.6 Software tool to estimate the latency of Thread mesh network 38

List of Tables

2.1 Thread compare with other protocols ...... 12

3.1 Unicast latency test plans ...... 17 3.2 Multicast latency test plans ...... 17

4.1 Experimental setup parameters for unicast latency ...... 22 4.2 Experimental setup parameters for multicast latency ..... 23 4.3 Experimental setup parameters for availability test ...... 24

5.1 Signal coverage result (meters) ...... 25 5.2 Statistics of the Round Trip Time (RTT) ...... 27 5.3 Reliability of multicast ...... 29 5.4 Statistics of the Time for Complete Coverage (TCC) ..... 29

6.1 Experimental data of the Thread latency in different layers with data length 10 Bytes ...... 35

List of Abbreviations

6LoWPAN IPv6 over Low power Wireless Personal Area Networks ACK Acknowledgement BA Building Automation BAS Building Automation System BPSK Binary Phase-Shift Keying BR Border Router CCA Clear Channel Assessment CDF Cumulative Distribution Function CoAP Constrained Application Protocol CSMA/CA Carrier Sense Multiple Access with Collision Avoidance DSSS Direct Sequence Spread Spectrum ED End Device IEEE Institute of Electrical and Electronics Engineers IETF Internet Engineering Task Force IoT Internet of Things IP Internet Protocol IPv6 Internet Protocol version 6 LLNs Low-Power and Lossy Networks MAC Media Access Control MCU Microcontroller MTU Maximun Transmission Unit MTTF Mean Time To Failure MTTR Mean Time To Repair NIP Native Internet Protocol NWK Network layer O-QPSK Offset Quadrature Phase-Shift Keying OS Operating System OSI Open System Interconnection OTA Over The Air PER Packet Error Rate PDR Packet Delibery Ratio PHY Physical PGF Probability Generation Function PLC Power Line Communication SPI Serial Peripheral Interface RPL IPv6 Routing Protocol for Low-Power and Lossy Networks RSSI Received Signal Strength Indicator RTT Round Trip Time TX Transmit TCC Time for Complete Coverage TCP Transmission Control Protocol TDMA Time Divesion Multiple Access UART Universal Asychronous Receiver/Transmitter xii

UDP User Datagram Protocol WiBA Wireless Buildling Automation WPANs Wireless Personal Area Networks WSN Wireless Sensor Network 1

Chapter 1

Introduction

The first chapter describes the structure of this master thesis. In the first section, the motivation is presented, giving a brief background introduc- tions to the field of home automation (HA) and wireless sensor networks (WSNs). Then the specific problems, which need to be solved are high- lighted. Furthermore, the methodologies applied in order to solve the problems effectively are discussed. Finally, this chapter clarifies the overall contributions, most significant parts of this thesis work.

1.1 Background

Internt of Things (IoT) , commonly considered as "the next generation of Internet" , has had a huge impact on human life. IoT, a complex cyber- physical system combining various kinds of sensors, actuators, networking, communication and information management technologies is reshaping the modern industrial systems, such as the ones in industry automation control and building automations (BA). Building Automation System (BAS) is an intelligent system that controls the electrical and mechanical systems in the buildings, like measuring the environmental factors, keep- ing the building safe and controlling the actuators intelligently. With the advanced development of IoT, BAS has been reshaping the future of buildings, considering not only the functionalities, but also the user friendliness, low energy consumption, high reliability and so on. Even though BAS has brought many advantages in our daily life, the installation and upgrade of BAS are much harder than we expected. Early type of home automation devices communicate using wired technologies like KNX and PLC, which need to be installed at the beginning of construc- tion. In modern BAS, migration from wired to wireless sensor network (WSN) technologies is becoming increasingly popular, like wirelessHART, Zigbee Pro, 6LoWPAN and Thread. WSN technologies have gained significant popularity in home automation due to its scalability, system mobility, wireless connectivity, cheap and easy commissioning(Sauter et al., 2011). A WSN consists of a group of specially conﬁgured nodes which can communicate with each other by radio technologies. Each node is typically composed of a controller, a transceiver, sensor/actuators, memory and power supply. The controller and memory implement the software stacks aiming to collect the data from sensors or to instruct the actuator. The radio transceiver being connected to the internal or external antenna is responsible for transmitting data packets. The transceiver consumes a large share of the energy of a sensor node. The ways of power supply can be main power, batteries or even energy harvesting. 2 Chapter 1. Introduction

Due to the advantages of easy installation, flexibility and low installation cost, Wireless Building Automation (WiBA) has been applied to fill the gaps of Wired Building Automation. Current WSN protocols, like Zigbee, IETF, 6LoWPAN, are often designed to be lightweight and power efficient. By using the sleeping mechanism, the end devices can last for several years using the same battery.

1.2 Problem Statement

WSN nature makes the network easy to scale to large dimensions and to modify the node locations. However, devices are also easily interfered by other kinds of wireless technologies, which makes the performance of WSN hard to predict. Thus, before utilizing the new wireless protocol, it is sig- niﬁcant to validate its performance to check whether the quality of service provided ﬁts the requirements of BAS. Thread, a new protocol aiming for HA, is proposed by Thread Group. Thread has the features of low energy consumption, low latency and high reliability. However, the performance has not been experimentally studied yet. This thesis provides experimental studies for Thread protocol, quanti- tatively evaluate the performance:

signal coverage; • unicast latency and reliability; • multicast latency and reliability; • availability. • In order to obtain the performance mentioned above, a large scale WSN network needed to be set up. Automatic tools need to be develop, without spending too much labors and time, which is an engineering challenge. The problem can be divided into three steps. First, design the test cases to make sure that the experiments can effectively measure the performance of Thread network. Second, implement the test cases and perform the experiments. Finally, analyze the experimental results. Due to the instability and uncertainty of WSN, it is challenge to modeling the behavior of WSN. In addition to the test, this thesis also presents the system level model of the unicast latency and develop a friendly tool for installers with respect to multihop latency of Thread network.

1.3 Methodology

In order to select the best-suited methods, a collection of research methods and methodologies is provided in (Håkansson, 2013). As the ﬁgure 1.1 shows, the left side refers to the methods for quantiﬁcation research while the right sides is for qualitative search. Moving from the left to right, the research methodologies change from being quantitative to qualitative. As case studies are used in this thesis, both the quantitative and qualitative research methodologies is used. For quantitative research, several experiments are performed to validate the performance of Thread network. 1.4. Contribution of the Thesis 3

FIGURE 1.1: The portal of research methods and methodologies(Håkansson, 2013)

Also, the computational mathematics are applied to analyzed the unicast latency of Thread mesh network. For qualitative research, the testing data are collected and data analysis is performed. The outcomes of these two methods complement each other, which lead to a better conclusions.

1.4 Contribution of the Thesis

The main contributions of this thesis as follows:

case study and experimental evaluation of Thread network with the • respect to signal coverage, unicast and multicast latency, reliability, and availability;

modeling and validation the latency in a Thread mesh network as • well as designing the corresponding tool for installers.

1.5 Outline

In chapter 2, the related works about WSNs are described, including trend of BAS moving from Non-IP to IP, the prevalent WSNs protocol stacks, and the overview of Thread protocol. Chapter 3 shows the case study design and performance metrics used in our experimental test. Besides, how these test cases are carried out and the implementation are described in Chapter 4. In chapter 5, the experimental results are presented and discussed. In chapter 6, an system level model for unicast latency is presented and experimentally validated. Finally, the conclusion and future work are discussed in chapter 7.

Chapter 2

Related work in Wireless Sensor Networks

2.1 From Non-IP to Native IP

Due to the interoperability challenges during system integration of different devices and value-added services from various suppliers, the support of Internet Protocol (IP), the so-called Native IP (NIP), in lightweight sensor devices is a promising direction for the communication technologies of BA systems (Pang et al., 2015). NIP means the communication protocol applies IETF IPv4 or IPv6 between its Data Link Layer and Network Layer, and thus it can support IP-based upper layer protocols and can be integrated into IP-based systems without heavy protocol translation or networking gateway. NIP technologies also allow the BA industry to beneﬁt from the fast innovations in Internet domain which has been developed in the past 30 years. In a piratical scenario, the efforts toward transforming Non-IP to native IP technologies have been clearly observed in many established BA communication standards, both in wire and wireless, e.g. KNX has released the KNXnet/IP(Ruta et al., 2014), BACnet has released BACnet/IP(BACnet Ofﬁcal Website), Zigbee has released Zigbee/IP(Alliance, 2013), DECT ULE is developing the 6LoWPAN-over-ULE(Mariager and Petersen, 2013), and Bluetooth is developing the 6LoWPAN-over-BLE(Nieminen et al., 2011). Furthermore, some WSN standards have already adopted the NIP connectivity, e.g. IEEE 802.11ah Low Power WiFi(Low Power WiFi), Thread Group(The Thread Group), and the IETF IoT stacks (6LowPAN, RPL, CoAP) (Palattella et al., 2013). Although the landscape of standardization is still fragmented, the BA industry has reached a consensus to adopt NIP connectivity technologies in the future.

2.2 Overview of the IEEE 802.15.4 standard

The IEEE 802.15.4 is a wireless standard, deﬁning the physical layer (PHY) and digital link layer (DLL) which consists of the MAC and LLC sublayers (Farahani, 2011). The PHY is responsible for taking care of the activation, deactivation of the radio transceiver, clear channel assessment (CCA) for the carrier sense multiple access with collision avoidance (CSMA/CA) and data transmission and reception among other things(Association, 2011). It can operate in many different frequencies but one of the most commonly used worldwide is the 2.4 GHz band, which consists of 16 available channels, and it employs the direct sequence spread spectrum (DSSS) technique which uses offset quadrature phase-shift keying (O-QPSK) modulation (Petrova 6 Chapter 2. Related work in Wireless Sensor Networks et al., 2006). The bit rate, in this case, is 250 Kbps and the chip rate is 2000 kchip/s. There is also the 868 MHz PHY that is commonly used in Europe and for this frequency there is only one available channel. It uses binary phase-shift keying (BPSK) for the modulation, the bit rate 20 Kbps and the chip rate is 300 kbit/s (Association, 2011). There are several possible ways of implementing this standard, it has for example one beacon-enabled mode and one non beacon-enabled mode depending on the kind of application it will be used for. It also has the op- tion to use super-frames. The MAC layer is responsible for generation of beacons (if the device is an access point), device security, employing channel access methods and enabling a reliable link between peers and other things. The channel access method that is used is CSMA-CA. (Association, 2011) There are several security measures implemented in the 802.15.4 as a part of the MAC layer. There is a choice between an unsecured implementation and a secure implementation. The unsecured mode contains no security measures whatsoever and is therefore not highly recommended. The secure mode has the functions: access control, data conﬁdentiality or encryption, data authenticity or integrity and replay protection or sequential freshness.(Laboratories, 2014)

2.2.1 Non-beacon enabled IEEE 802.15.4 CSMA/CA This section introduces non-beacon enabled IEEE 802.15.4 CSMA/CA which is also used in Thread protocol. Figure. 2.1 depicts the ﬂowchart of unslotted IEEE 802.15.4 CSMA/CA channel access mechanism. Upon transmitting packets, MAC layer performs the following steps (initialize retransmission counter R to 0, the number of backoff (NB) to 0 and backoff exponential (BE) to macMinBE).

1. Before sending the packets, waiting for a random period of time in the range [0, 2BE 1] in order to avoid collision. The backoff time unit is 20Ts with Ts = 16µs.

2. Perform Clear Chanel Assessment (CCA) to check if the channel is busy or idle. If the channel is idle, it goes to the step 4, otherwise it goes to step 3.

3. Busy channel: the values of NB and BE will increase by one. However, the maximum value of BE is macMaxBE. At this time, if value of NB is less than macMaxCSMABackoffs , the algorithm returns to step 1. Otherwise, the algorithm terminates with a channel access failure.

4. Idle channel: the MAC layer sends out the packet and waits for the ACK. If ACK is received within maximum macAckW aitDuration, the packet is successfully sent. Otherwise, the packet has collided and needs to be retransmitted. If R excesses macMaxF rameRetries, the algorithm terminates with collision fail and the packet is discard. Otherwise the algorithm initializes the NB and BE again and returns to step 1. 2.3. IETF IoT stacks 7

FIGURE 2.1: The unslotted IEEE 802.15.4 CSMA/CA channel access mechanism

2.3 IETF IoT stacks

In the past few years, IETF has established many working groups towards the Internet of Things, e.g. 6LoPWAN, ROLL and CoRE working groups. They are trying to integrate contained devices into the Internet and stan- dardize the IP-based Low-Power and Lossy Networks protocols. Figure. 2.2 presents how different LLN standards ﬁt together. Currently this entire LLN stack protocol is available in Contiki OS. IEEE 802.15.4 standards have been introduced in the last sections, therefore, the following sections will describe the standards of 6LoWPAN, RPL and CoAP.

2.3.1 6LoWPAN IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) is an adaption layer that allows sending IPv6 packets within small link layer frames(Hui, Culler, and Chakrabarti, 2009). It has been used to send and re- ceive IPv6 packets over 802.15.4 links. In the Ethernet link, the IPv6 packets within MTU (1280bytes) can be easily send as one frame. However, IEEE 802.15.4 has maximum 127 bytes packet size at the PHY layer while as low as 88 bytes in MAC layer payload. In this situation, 6LoWPAN can act as an adaption layer between IPv6 network layer and 802.15.4 link layer by fragmenting the IPv6 packets at the sender and reassembling them at the 8 Chapter 2. Related work in Wireless Sensor Networks

Protocol stacks for IETF IoT Protocol stacks for Thread Application (CoAP) CoAP/HTTP

Transport(UDP) UDP

Network(IPv6 with RPL) IP Routing

Adaption(6LoWPAN) 6LoWPAN

IEEE 802.15.4 MAC IEEE 802.15.4 MAC

IEEE 802.15.4 PHY IEEE 802.15.4 PHY

FIGURE 2.2: IETF LLN protocol stack receiver. Furthermore, a compression mechanism is developed in 6LoW- PAN to reduce the IPv6 headers size thus reducing transmission overhead. The details of describing the packet fragmentation and header compression can be found in RFC4944 (Montenegro et al., 2007) and RFC6282 (Hui and Thubert, 2011). An other signiﬁcant usage of 6LoWPAN layer is to provide link layer packet forwarding. It provides an efﬁcient and low-overhead mechanism to forward multihop packets in mesh networks. Thread uses IP layer routing and link layer packet forwarding, thus avoiding parsing the packets to network layer. In addition, Thread utilizes the MAC layer short address (16-bit length) to further reduce th information bits need to be sent over the air. In this way, processing cycles and power consumption are reduced while still using the IP based routing protocols. By the use of IP-based protocol, HA applications can increase interoperability the other IP technologies and value-added service from different suppliers.

2.3.2 RPL In 2008, a new Working Group Routing over Low power and Lossy networks (ROLL) was founded by IETF to standardized the IPv6 based routing solution for LLNs. IPv6 Routing Protocol for Low-Power and Lossy Net- works (RPL) is a routing protocol mainly designed for low power WSNs (Winter, 2012). The RPL speciﬁcations give a detailed information about the routing behavior, packet formats and so on. A tree-like topology is created in an RPL network and every ROL instance has at least one RPL Destination-Oriented Directed Acyclic Graph (DODAG). Every DODAG has only one root and several leaf nodes. In RPL networks, DODAG Information Obeject (DIO) and Destination Advertise- ment Object (DAO) messages are used periodically to form and maintain the topologies. If there is one node fail in the network, RPL can immediately switch to another route. In this way, the network is kept stable. Both upward and downward directions are supported in RPL networks via single or multihop packets. Furthermore, RPL has the mechanism to prevent the occurrence of routing loops in the occasion of node failures and packet losses. 2.4. Overview of Thread protocol 9

RPL is able to meet different network requirements by choosing the designs and conﬁguring the parameters. Recommendations for Efﬁcient Im- plementation of RPL (draft-gnawali-roll-rplrecommendations-04) (Gnawali and Levis, 2013) describes various design choices and parameters when using different RPL implementations and operations. Performance Evalu- ation of the Routing Protocol for Low-Power and Lossy Networks (RPL) (RFC 6687) (Tripathi, Oliveira, and Vasseur, 2012) presents two different use case : a small outdoor deployment for BA and a large-scale network for smart meter network, both of which can meet the desired requirements.

2.3.3 CoAP In 2010, IETF has established another working group, call Constrained REST- ful environment (CoRE), in order to work on a framework that can utilize RESTful web services for resource constrained embedded devices. These works are standardized in a protocol called Constrained Application Pro- tocol (CoAP) in draft-ietf-core-coap (Shelby et al., 2012). CoAP is like a lighter version of HTTP, having the same RESTful prin- ciples, in order to be run on resources constraint embedded devices. CoAP has a much lower header overhead and parsing complexity than HTTP, e.g. it just uses four-bytes base binary header. Furthermore, CoAP has adopted many similar HTTP patterns and features, such as URIs and resource abstraction. By using URIs, CoAP is able to easily communicate with World Wide Web (WWW). However, CoAP just uses UDP protocol rather than TCP which is considered to have a poor performance in resource- constrained devices with respect to energy consumptions. CoAP provides retransmission mechanism to increase the reliability of the WSN. Conﬁrmable (CON) messages can be used in the client to ask for the ACKs from destination nodes. If the waiting time in sending node ex- pires and ACK is still missing, the sender will retransmit the CON message within the maximum retransmission times. The mechanisms of retransmission and other message types are provided in the standard (Shelby et al., 2012).

2.4 Overview of Thread protocol

2.4.1 Protocol stacks Thread is a new IP based wireless networking protocol established in July 2014 by Google Nest, ARM, Samsung, and some other companies (The Thread Group). The Thread protocol combines the best parts of several standards to achieve a great performance aiming at BA applications. As the ﬁgure 2.3 shows, Thread has not standardized the application layer, which provides the supplier with the freedom to use proper application layers according to their needs. The feature supporting the IP allows Thread easily to interconnect with other IP-based mobile devices. As for the network layer (NWK) in Thread, UDP is used on top of IP routing and 6LoWPAN. In MAC and PHY layer, Thread uses the IEEE 802.15.4 wireless speciﬁcation, supporting mesh network with a maximum speed of 250kbps in the 2.4 GHz band(The Thread Group). 4

10 Chapter 2. Related work in Wireless Sensor Networks

Figure 1. Overview of Thread Stack FIGURE 2.3: Thread protocol stacks. IEEE 802.15.4 2.4.2 Device types This standard is based on the IEEE 802.15.4 [IEEE802154] PHY (Physical) and MAC (Media Flexible:Access Simplified Control) layer Devices operating Types at 250 kbps in the 2.4 GHz band. The IEEE 802.15.4-2006 version of the specification is used for the Thread stack. • Devices join as RouterThe Eligible 802.15.4 or EndMAC Device layer is used for basic message handling and congestion control. This MAC layer includes a CSMA (Carrier Sense Multiple Access) mechanism for devices to listen for a clear channel, as well as a link layer to handle retries and acknowledgement of messages for reliable • Router Eligible: Can becomecommunications Routers between if needed adjacent devices. MAC layer encryption and integrity protection is used on messages based on keys established and configured by the higher layers of the • First router on networksoftware becomes stack. Leader The network layer builds on these underlying mechanisms to provide reliable end-to-end communications in the network. • Leader: Makes decisionsNo within Single network Point of Failure • End Devices: Route throughIn a system parent comprised of devices running the Thread stack, none of these devices represents a single point of failure. While there are a number of devices in the system that perform special functions, the design of the Thread stack is such that they can be replaced without impacting • Can be “sleepy” to reduce power consumption

FIGURE 2.4: Thread device types(Threadgroup ofﬁcial website)

Figure. 2.4 shows the device types deﬁned in Thread network: Border routers (BR), routers, router-eligible end devices (REED) and sleepy end devices (ED).

BR is a speciﬁc router which can connect IEEE 802.15.4 networks to • other physical networks like Wi-Fi or Ethernet. BR also provides services for the devices in the Thread mesh network. There can be several BRs in the network. A BR can become leader if it is the ﬁrst router in the network. 2.4. Overview of Thread protocol 11

Routers provide routing services for devices in the network. Routes • also provide joining and security services for devices that want to join the network. Routers can become leader if they are the ﬁrst router in the network.

REED is able to become router depending on the topology of the net- • work. Usually REEDs behave like EDs which can not forward messages. The REEDs can become router if it is required by the network requires without user interaction.

Sleepy ED are host devices. They can not forward messages and only • communicate through their parents.

2.4.3 Multicast Protocol for Low power and lossy networks (MPL) Thread also introduces new protocols to support multicast feature which is signiﬁcant for applications in home automations, e.g. switch on/ off the a bunch of lights almost simultaneously. Multicast Protocol for Low power and lossy networks (MPL) is proposed as an IP standards intended for wireless mesh network(Hui and Kelsey, 2016). MPL provides IPv6 multicast forwarding in constrained networks and avoids the maintain the multicast routing topology. Two execution modes, reactive and proactive are speciﬁed in MPL and Thread just uses proactive mode. MPL algorithm is developed from the Trikle algorithm (Levis et al., 2004). Trikle algorithm is used to spread operational network values to the distributed network by minimizing the load of the network. By using Trikle algorithm, constrained devices only need small, constant state to dissemi- nate the multicast message. What’s more, MPL also aware the density of the network and it communication rate can adapt to the density change loga- rithmically. The details of the algorithm can be found in (Hui and Kelsey, 2016).

2.4.4 Comparison with other protocols In comparison with other popular wireless protocols, Thread has many advantages, as shown in the table 2.1. Here are some features of Thread mesh network:

Low power consumption: According to the white paper from Thread • (The Thread Group), the Thread sleeping devices are using polling methods, which means they just wake up for an interval time. This method saves a lot of energy extending the battery life time up to 2.6 years.

IP based protocol: The support of IP increases the interoperability • with other devices. All the devices that support IP can exchange information smoothly, making it easy for users as they do not need to worry about the problem of interoperability.

Not single point of failure: Thread is no need of a coordinator and it • supports self-healing. Some devices have a critical role in the homes, like regulating the power off/on. It is crucial to provide stable services without failures. 12 Chapter 2. Related work in Wireless Sensor Networks

TABLE 2.1: Thread compare with other protocols

function WiFi Zigbee Zigbee Z-Wave Thread PRO IP-SE 2.0 Low Power Con- 73733 sumption Mesh network 7337limited 3 support Support for IPv6 77773 interoperability 37 Not 7limited 3 clear Open Standard 3337 3

Security: Thread networks use a smart phone era authentication scheme • and AES encryption to close security holes that exist in other wireless protocol. Thread is using IEEE 802.15.4 encryption and authentication and can also support IP based encryption methods.

2.5 Other protocols

2.5.1 Zigbee The role of ZigBee is to provide its services for the connection of various sensors and additional apparatus in the customers’ local area network (OECD, 2009). ZigBee is accompanied by a low cost of implementation (less than 3$ per node), highly satisfactory scalability levels (64 000 nodes with a single coordinator) and a dependable coverage of 100m. ZigBee systems possess additional appealing features, for instance, adjustable timeliness which can be acquired at the expense of higher power consumption and sufﬁcient security, if compared to other standards (Liu, 2012). Its low data rate architecture of 250Kbps might be regarded as a con, however, the rate is more than adequate for the target applications.

2.5.2 WirelessHART and ISA100

WIRELESSHART and ISA100 are two competing but equally competent standards in the industry of process automation and manufacturing. In spite of the fact that the two standards have their own distinct technical features, they bear a resemblance in their rudimentary communication parameters, for example, they both allow a data rate up to 250 Kbps and with the maximum transmission power of 10 mW, the transmission range is ex- tended to reach 100 meters of coverage (Liu, 2012). Both standards deploy a combination of DSSS and frequency-hopping spread spectrum (FHSS) as modulation technique which is a slight modiﬁcation of the modulation that takes place in IEEE 802.15.4. They can expand their networks and incorpo- rate from 50 up to 100 sensors (in large mesh networks), technically though 2.5. Other protocols 13 they can accommodate and handle thousands of devices but the limit is set due to network performance degradation after some point (Petersen and Carlsen, 2011). The channel access method implemented, in both cases, is time division multiple access (TDMA) combined with frequency hopping. WIRELESSHART is viewed as a fault-tolerant standard because it can con- tinue to successfully operate in occasions of single or even multiple sensor node failures (Akyol et al., 2010). ISA100 is robust in the matter of interference and it additionally utilizes congestion notiﬁcations in the presence of overloaded networks (Nixon, 2012).

Chapter 3

Test plan

This chapter introduces test case designs which reveal the performance of Thread network. Four test cases is proposed in order to evaluate the network quality with latest hardware platform and cutting-edge of software protocols. The performance metrics of signal coverage, unicast latency and reliability, multicast latency and reliability, and availability of Thread network are investigated. All the tests are carried out in ABB Corporate Re- search Center, Sweden.

3.1 Signal Coverage

Signal coverage is the communication range between the nodes in WSNs, which is the fundamental and crucial feature for setting up the networks. In (Woo, Tong, and Culler, 2003), the communication range is separated into three regions according to packet error rate (PER): effective region (PER consistently < 10%), poor region (PER consistently > 90%) and transitional region (anything in between can be observed, large variation for nodes at same distance). Although the signal coverage can be calculated by signal theory, it is not sufﬁcient in the real case building. The real signal coverage is largely inﬂuenced by transmit power and the surroundings. Hence, the real case study is performed in order to measure the signal coverage. Another purpose of this test is to compare the signal coverage performance with IETF IoT protocol which is also based on IEEE 802.15.4. Even though several protocols operate at the same frequency 2.4GHz and are also based on IEEE 802.15.4, the communication range may varies with respect to different software stack implementations and hardware platforms. This signal coverage test is divided into four categories by different software stack implementations and hardware platforms.

KW24D512 802.15.4 SMAC test case 1 • KW24D512 802.15.4 Thread test case 2 • CC2650 802.15.4 MAC test case 3 • CC2650 802.15.4 6LoWPAN test case 4 • Each test case contains one sender and one receiver. The ﬁrst two test cases are applied in the hardware platform KW24D512 from NXP company. Sim- ple Media Controller (SMAC) is a small base code provided by NXP company, offering communications and test applications based on the 802.15.4 compliant PHY (SMAC Wireless connectivity made easy). In this way, the 16 Chapter 3. Test plan

packet delivery rate is purely measured in physical layer without MAC layer retransmission. The second test case implements the whole Thread protocol containing more layers and different headers. In this group, MAC layer retransmission is used and the PDR is measured by round-trip packet. The last two test cases use the hardware platform CC2650 EM. In the third group, the sender sends the standard IEEE 802.15.4 packets without payload. In the fourth group, the Contiki network protocol is used to send the 6LoWPAN packet to the receiver using round-trip packet. Note that the ﬁrst and third groups use the receivers to display the reception messages while the second and fourth cases display the ACK messages in the senders.

3.2 Unicast latency and reliability

The unicast latency and reliability are crucial in BAS as many applications in the BA have limited delay to guarantee the quality of service (QoS). There is a considerable amount of research done in these areas. In the work (Kruger and Hancke, 2014), the authors have tested the latency of IETF IoT stacks based on TinyOS Blip 2.0 IP and TinyRPL with respect to different topologies in the mesh network. The work in (Djamaa et al., 2014) has investigated the unicast and multicast latency in single hop duty-cycled 6LoW- PAN networks using Contiki. However, there are no related researches on experimental studies of Thread protocol. This work is the first attempt to experimentally evaluates the latency and reliability of Thread network. In order to measure the unicast latency, a multihop mesh network is set up based on our test platform. Round trip time (RTT) is used to indicate the unicast latency of the network. RTT is defined as the time duration from the border router sending out a message in the application layer (e.g. CoAP request ) until receiving the response from the destination(e.g. CoAP ACK). More details are shown in the figure .3.1 . 20 Bytes at APP layer, for CoAP GET command and CoAP ACK command separately. Traffic flow between each IETF Device is initialized to have the same length as the flow between IETF BR and IETF Device at APP layer. The difference is that they have 61, 62 or 70 Bytes and 71, 72 or 80 Bytes at PHY layer for CoAP GET command and CoAP ACK command.

B. Definition of Test Cases

To cover all practical scenarios in BA, four test cases were Fig. 4. Definition of Round Trip Time (RTT) between BR and designed as follows: FIGUREDevices3.1: with Definition different of number round tripof hops time TC1 BurstOff-Load0: to simulate the typical case in practice. According to the piratical traffic scenario, four test cases are going to The time interval between each round of test is 500ms, be implemented. TheCDF firstRTT one (t) is= aP typical (RTT caset in) practice: no added (1) load which means BR delays sending the next test packet for in theThe network right-hand with packets side represents interval time the 0.5s. percentage The other of three the testtest cases 500ms after the previous round of test is finished. There are medium,CoAP requests heavy and that very get heavy responded load cases before based a on certain the traffic time load t and is no extra load in the network. packetsamong interval the time. entire Details test CoAP are shown requests. in table 3.1.

TC2 BurstOff-Load0.2: to simulate the heavy load case. The • time interval of each round of test is 500ms, which PDR-by-Deadline (Packet Delivery Ratio): According to means BR delays sending the nest test packet for 500ms different user cases, there exist different criteria of after the previous round of test is finished. Each device deadlines to judge if a packet is delivered successfully. sends CoAP GET message to a randomly selected device PDR represents the percentage of the test CoAP requests every 5s and waits for CoAP ACK message. that get responded before a predefined time t among the entire test CoAP requests. For example, in our case, the TC3 BurstOn-Load0: to simulate the medium heavy load latency deadline for delay-sensitive user case is 200ms. case. The time interval between each round of test is 0, So the PDR-by-200ms is: which means BR sends test packet immediately after the previous round of test is finished. There is no extra load PDR200ms = P (RTT ) (2) in the network. D. Latency TC4 BurstOn-Load0.2: to simulate the very heavy load case. Fig. 6 shows the CDF of the RTT for different test cases. It The time interval between each round of test is 0, which can be seen that as the number of hops increases, the means BR sends test packet immediately after the probability of getting the deadlines is decreasing whatever the previous round of test is finished. Each device sends test case is. Comparing the load case and no load case, it is CoAP GET message to a randomly selected device every easy to find that the performance is degraded with extra traffic 5s and waits for CoAP ACK message. in the network. The degradation for 3-hop and 4-hop devices is much more serious than 1-hop and 2-hop devices. And it also C. Definition of Evaluation Criteria can be seen from the curves that for 1-hop and 2-hop devices, • the probability of achieving 200ms deadline is always higher RTT (Round Trip Time): the time duration from BR than 0.9 in all of the test cases. However, for 3-hop and 4-hop sends out a test CoAP request until receiving a CoAP devices, even in TC1 the light load case, the probability is response or timeout. RTT is calculated by BR and around 0.7 and 0.25 respectively. In other 3 test cases, the counted per System Tick of the BR. More details are probability is even lower, almost around 0.1. The performance shown in Fig.4. RTT is the measurement for latency in for more than 2-hop devices is extremely unfavorable for this test. delay-sensitive cases. There is also a common characteristic of • CDF (Cumulative Distribution Function): CDF is used all of the curves, which is called Stair Effect. It will be to analyze the statistical distribution of the RTT to give discussed further later. more insight.

Fig. 5. Deployment for the nodes in the building 3.3. Multicast latency and reliability 17

TABLE 3.1: Unicast latency test plans

No. Name Test Packet Added Load Practical scenario 1 burstoff- BR sends the next test No Typical load0 packet (CoAP request) case in 500ms after the previ- practice ous round of test is ﬁnished (request is responded or timeout) 2 burstoff- Same as above Every device Heavy load load0.2 sends CoAP cases request to a randomly chosen device per 5 seconds 3 burston- Burst mode, BR sends No Medium load0 the next test packet load cases (CoAP request) immediately after the previous round of test is ﬁnished (request is responded or timeout) 4 burston- Same as above Every device Very heavy load0.2 sends CoAP load cases request to a randomly chosen device per 5 seconds

TABLE 3.2: Multicast latency test plans

No. Name Test Plan 1 Reliability Send a large amount of multicast messages from BR and check how many messages are successfully received by the nodes in the network 2 TCC Send a large amount of multicast messages from BR and count the time for complete coverage of the network of each multicast message

3.3 Multicast latency and reliability

Multicast function plays an important role in the applications of BA when it comes to large area control in the buildings, e.g., controlling an area of sensors or actuators spontaneously with only one switch. Hence, it is nec- essary to ﬁgure out the multicast latency performance of Thread network. 18 Chapter 3. Test plan

A large-size network, 38 nodes, is set up in the buildings in order to perform multicast latency and reliability test. Time for complete coverage (TCC) is deﬁned to evaluate the multicast performance of Thread network. TCC means the time duration from the BR sending the multicast message until all nodes in the network have successfully received by this multicast message.

3.4 Availability

The applications in BA generally demand stringent availability requirements, since faults may lead to malfunctions of the systems, which can cause economics losses or human injuries. In this context, faults can be clas- sified as transient or permanent(Avizienis et al., 2004). Transient faults are caused by noise or electromagnetic interferences affecting the links between communications. Permanent faults are caused by the hardware malfunctions causing the devices to permanently fail. This test is mainly focused on transient faults. The availability is defined as the probability of a component/device is working correctly during a period of time. We can define availability A as (Rausand and Høyland, 2004):

MTTF A = (3.1) MTTF + MTTR MTTF means the mean time to failure while MTTR represents the mean time to repair. In this test, a large network is established to evaluate the availability of Thread mesh network. The set up of the test is introduced in the next chapter. 19

Chapter 4

Experimental Setup

Features

1 Features 4.1 Test platformThis section provides a simplified block diagram and highlights the device features.

1.1 Block diagram

Core System Memories RF Transceiver Internal and Program Flash ARM® CortexTM –M4 IEEE 802.15.4 2006 External (up to 512 KB) 50 MHz Watchdogs FRDM-KW24D5122.4 GHz Overview and Description FlexNVM — Programmable output power from -35 dBm to +8 dBm at the SMA connector, no trap Debug 64 KB Dual DSP DMA Antenna Diversity Interfaces 4 KB FlexRAM PAN ID — Receiver sensitivity: -102 dBm, typical (@1%MKW21D256 PER for only 20 byte payload packet)

• Integrated PCB inverted F-type antenna and SMA RFSRAM port 32 MHz Interrupt Controller SPI Low‐Leakage (up to 64 KB) OSC • Selectable power sources Wake‐up Unit • 32 MHz reference oscillator Security Analog Timers Communication Interfaces Clocks • 32 kHzand clock Integrity oscillator FlexTimer Phase‐Locked Cyclic • 2.4 GHz frequency operation16‐bit (ISM Band) USB On‐the‐Go Loop Redundancy ADC Programmable I2C Check (CRC) (HS) • External serial flash for over-the-airDelay programming Block (OTAP) support Frequency Locked Loop Tamper Detect USB Device • Integrated open-standardHigh‐Speed serial andPeriodic debug Interrupt interface (OpenSDA)UART Charger Detect Comparator Timers (ISO 7816) Low/High Cryptography (DCD) • Cortex 10-pin (0.05 inches)with 6‐bit SWD debug port for target MCU Frequency Authentication DAC Low‐Power Unit Timer Oscillators • Cortex 10-pin (0.05 inches) JTAG port for OpenSDA updatesUSB Voltage SPI Regulator Internal • 1 RGBRandom LED Number indicator Independent Real‐Time Reference Generator • 1 Blue LED indicator Clock (RTC) Clocks

• 4 Push Standardbutton Featureswitches Optional • FXOS8700 Combo SensorFigure 1. MKW2xD simplified block diagram Figure 2 shows the( Amain)MKW2xD platform features and simpliﬁed I/O headers for blockthe FRDM diagram-KW24D512 platform.

1.2 Radio features • Fully compliant 802.15.4 Standard transceiver supports 250 kbps data rate with O- QPSK modulation in 5.0 MHz channels with direct sequence spread-spectrum (DSSS) encode and decode

4 MKW2xD Data Sheet, Rev. 2, 05/2016 NXP Semiconductors

Figure 2. FRDM-KW24D512 components and I/O headers (B) FRDM-KW24D512 components and I/O headers Freedom Development Board FRDM-KW24D512 User’s Guide, Rev. 1, 05/2016 NXP SemiconductorsFIGURE 4.1: Hardware platform - FRDM-KW24D512 5 (MKW2xD Data Sheet)(FRDM-KW24D512 Freedom Development Platform User’s Guide)

Figure. 4.1 shows the hardware platform - FRDM-KW24D512 used in our experimental test. FRDM-KW24D512 is a development platform based on MKW24D512 MCU and supports various wireless protocols like Thread, ZigBee Pro, 802.15.4 MAC and IPv6/6loWPAN. The components and I/O headers on FRDM-KW24D512 board are shown in the ﬁgure. 4.1b. 20 Chapter 4. Experimental Setup

MKW24D512 consists of a low power 2.4Ghz IEEE 802.15.4 compliant radio transceiver and a 50 MHz ARM Corter-M4 MCU with DSP capabili- ties. MKW24D512 owns up to 512 KB of flash memory and 64KB of SRAM. It is typically designed for control and monitoring applications for home and building automation like meters, gateways, lighting control, HVAC and security. The system simplified block diagram of MKW24D512 is presented in figure. 4.1a.

4.2 Signal Coverage Setup

Figure 4.2 shows the environment that is set up for signal coverage test. The green dot in the ﬁgure represents the sender placed on the ofﬁce desk, which implemented the software stack that needs to be test. The red dot represents the receiver that moves along the corridor.

sender

receiver

Scale 1:200 Building 206 Floor 3 5m Building 207 Floor 3 Building 208 Floor 3 10m

FIGURE 4.2: Signal coverage test setup

When the test program begins, the sender sends the packets continuously to the receiver. While at the same time, the receiver is gradually moving to the end of corridor, away from the sender. In this way, the RSSI and PDR information is collected to decide the distance the signal can reach. Then, we use the scale in the map to calculate the real distance. Note that this method of calculation contains small error deviations but it is acceptable as only the rough range needs to be obtained. Then the Tx power is altered for subsequent test.

4.3 Unicast Latency and Reliability Setup

Windows Native-IP based BAS PC Parent Links (mesh network) ...

UART BA Deevviiccee BA Deevviiccee

BA Deevviiccee BA Deevviiccee IPv6 ...

BA Deevviiccee BA Deevviiccee BA Gaatteewaayy BA Deevviiccee

Parent links (topology) BA Deevviiccee Test packets ... Test commands and result BA Device BA Deevviiccee Added load traffic BA Device

FIGURE 4.3: Thread mesh network topology 4.3. Unicast Latency and Reliability Setup 21

For the hardware set up, the unicast latency and reliability test consists of 23 FRDM-KW24D512 hardware boards. As the figure 4.3 shows, there is one node, the BA gateway, acting as BR being connected to the Windows desktop. The other 22 nodes are separately deployed in the buildings to set up the local Thread mesh network. As the right side of the figure shows, the boards are connected to a mobile power bank and put inside an engineering plastic box to guarantee the safety in the building. The red lines in the figure present the testing packets. The red dash lines represent the communication between the laptop and BR, which is discussed in the next paragraph. The green lines show the added traffic load between the nodes in the network, corresponding to the test case 2 and 4. The figure 4.4 shows the connections between the laptop and border router. The source codes of Thread protocol stacks are implemented in IAR 7.5 EWARM and the compiled file is downloaded into the KW24D board through USB port. After that, KW24D board connects to the laptop by its two USB ports. One of them is used as a connectivity shell, where the PC can send the testing command to BR and collect the RTT results back to PC to further process. The other USB port connects to a Remote Network Driver Interface Specification (RNDIS) that is a Microsoft proprietary protocol used mostly on top of USB. It provides a virtual Ethernet link to most versions of the Windows and Linux operating systems. In this way, the IPv6 packets can send through RNDIS from BR to PC or vice versa. In addition, Thread packet sniffer can connect to PC as well and provide packets traffic information.

Wireshark Web Brower IAR 7.5 Coap EWARM Python serial Kinetis Protocol Analyzer Adapter

USB Serial Port

Remote Network Driver Interface Specification (RNDIS) is a Microsoft proprietary protocol used Connectivity Shell RNDIS mostly on top of USB. It provides a virtual Ethernet link to most versions of the Windows and Linux operating systems. Thread Border Router Thread Sniffer KW24D USB- KW24D

IP Based Devices IP Based Devices IP Based Devices

KW24D

FIGURE 4.4: Communication between laptop and border router

Figure 4.5 shows the deployment of nodes in different floors on the buildings, setting up a multi-hop mesh network. Each node has an ID from 0 to 22. Node 0 is the BR where sending the RTT packets. Nodes 1 to 12 are the active routers, while nodes 13 to 22 are the ED. In the graph, the red circle in the third floor denotes the Thread BR, the root of the mesh 22 Chapter 4. Experimental Setup network, connecting to our desktop computer. Other nodes are spreading in the building from basement to third floor, mainly in the meeting rooms, lounges and corridors. The deployment of nodes is close to real network conditions used in BAs. The different colors mean the nodes are placed at different floors and the maximum number of hops in the network are 6 hops.

Border Router Floor 3 COAP Server Floor 4 Router:1-12 Floor 3 End Node: 13-22

Floor 2 02 Floor 1 Floor -1 13

BR 10 20 03 06

14 08 16 07 09 17 18

15 05 21 04 12 01 22 19

Building 206 Floor 3 Scale 1:200 Building 207 Floor 3 Building 208 Floor 3 5m 10m

FIGURE 4.5: nodes placement in the building

Table 4.1 shows the experimental parameter settings in the test bed. Channel 25 is used in order to avoid interference from other signals, like Wi-Fi. When the test begins, BR starts sending CoAP GET messages to each node from node 1 to 22. The BR uses its hardware clock to calculate the time interval between sending the message and receiving the ACK. Totally BR sends 300 packets to each node and records how many hops to reach fo each node. All the RTT data is divided into 6 groups according to the number of hops. For each hop, the cumulative distribution function (CDF) curves are drew to present the RTT. When trafﬁc mode is on, the BR sends LOAD commands to all the nodes in the network. Then the nodes start to send a CoAP message to a random node in the network every 5 seconds. The experimental results are analyzed in the next section.

TABLE 4.1: Experimental setup parameters for unicast latency

Parameters Value Platform FRDM-KW24D512 Channel 25 Transmit Power 5 dBm CoAP Max Retransmission 4 CoAP ACK Timeout 2000 ms RTT packet number for each 300 node Packet length CoAP GET: 10 Bytes at APP layer, 73 Bytes at PHY layer CoAP ACK: 20 Bytes at APP layer, 68 Bytes at PHY layer 4.4. Multicast Latency and Reliability Setup 23

4.4 Multicast Latency and Reliability Setup

Figure. 4.6 shows the 38 nodes deployment in the building for multicast test. In the third ﬂoor, node 0 is the BR sending the multicast messages. The connection between the BR and laptop remains the same in ﬁgure. 4.4. Nodes 1 to 17 are the active routers , while nodes 18 to 37 are the EDs. All of the nodes are deployed in the building’s meeting room, corridors and lounges, simulating the practical use cases.

FLOOR 3 21 22 18 12 1 Active Routers: 1-12 2 End Devices: 18-32 1 8 31 0

25 32 Scale 1:200 28 19 9 5m 2 BR 9 0 27 10m 4 5 3 24 23 11 30 20 7 26

6 Building 207 Floor 3 Building 208 Floor 3

14 Active Routers: 13-17 15 FLOOR 4 36 End Devices: 33-37 34

17 Scale 1:200 Floor 3 5m BR 37 10m 0 13 35 16 33

Floor 4

FIGURE 4.6: Deployment of Nodes in the building for multicast test

The experimental setup parameters for multicast latency are shown in table. 4.2. Note that the CoAP retransmission is not used in multicast situation.

TABLE 4.2: Experimental setup parameters for multicast latency

Parameters Value Platform FRDM-KW24D512 Channel 25 Address Muticast Transmit Power 5 dBm CoAP Retransmission No Packet length CoAP GET: 10 Bytes at APP layer, 73 Bytes at PHY layer 24 Chapter 4. Experimental Setup

4.5 Availability Test Setup

A large network containing 38 nodes is set up to measure the availability. The topology is the same as the multicast test shown in ﬁgure. 4.6. The parameters used in the test are shown in Table. 4.3. The is no CoAP retransmission during the test.

TABLE 4.3: Experimental setup parameters for availability test

Parameters Value Platform FRDM-KW24D512 Channel 25 MAC CSMA/CA Transmit Power 5 dBm CoAP Retransmission No Packet length CoAP GET: 10 Bytes at APP layer, 73 Bytes at PHY layer

As there is no standard method to measure the transient availability in WSN, a new method is proposed in this test. For example, we assume there are 37 nodes in the mesh network and 1 BR. During each run of the test that lasts 10 seconds, Coap Get command is sent to nodes from 1 to 37. If the BR receives the ACK from the node, then the node is available. Every 5 minutes the availability is calculated one time. For example, for 5 minutes, the BR has sent GET commands: 37 nodes (5 min/ 10 second) = 1110 ⇥ times. If BR receives 1000 ACKs during this 5 min, then the availability for this set is : 1000/1110 = 90.09%. The test is continuously running for 88 hours. 25

Chapter 5

Result Analysis

5.1 Signal Coverage

This section presents the test results of signal coverage. Table 5.1 shows the static result. As can be seen in the table, Tx power has a signiﬁcant impact on the signal coverage. The larger the Tx power, the longer the signal coverage distance. Besides, CC2655 generally has a better performance than KW24D irrespective of the software protocol. Here the dominant factor is the hardware platform. When it comes to the KW24D platform, SMAC out- performs the Thread protocol in general. The reason maybe SMAC is more lightweight than Thread. Also SMAC is tested using single trip message while Thread uses the round trip packets. For the round trip packets, the message has more chance to collide over the air. For the CC2650 platform, lightweight protocol 802.15.4 also beats 6LoWPAN protocol. The reason is similar to the platform KW24D. Another crucial factor is the wall between the sender and receiver. When there are more ﬂoors between the sensors and the receivers, the horizon distance decreases dramatically. This result provides fundamental data to set up the mesh network in the following section.

TABLE 5.1: Signal coverage result (meters)

Transmit Floor KW24D KW24D CC2650 CC2650 power SMAC Thread 802.15.4 6lowPAN (dBm) 3 C 44.5 36.8 66.3 60.5 B 32.3 32.3 34.0 28.7 K 8.5 7.3 12.3 10.3 -3 C 34.1 28.6 37.3 35.2 B 20.0 17.5 24.5 23.5 K NO NO NO NO -9 C 25.0 25.0 28.3 28.3 B 13.3 10.0 16.3 1.1 K NO NO NO NO 26 Chapter 5. Result Analysis

(A) burston-load0 (B) burstoff-load0

FIGURE 5.1: Latency result of 6 hops for 4 test cases

5.2 Unicast and Reliability

In this section, the experimental test result about latency is presented. The tests are performed in a very complex building environment having the interference from different wireless protocols, e.g. wirelessHART, Bluetooth, Wi-Fi. Nodes are placed in different floors in the building shown in Figure. 4.3 with walls between some nodes. All the test results are performed after the network is stable, an hour after the set-up of the network. Fig. 5.1 shows the latency result of the 6-hops network for four test cases mentioned in Chapter 4. In general, RTT increases with the number of hops. The CDF curve interval between each hops are closed to each other. There are also some test results more than 2 seconds because of the CoAP retransmissions. If the results are larger than 10 seconds, it means these CoAP messages are timeout. Comparing with figure. 5.1a and figure. 5.1b, the latency of LOAD cases in figure. 5.1c and figure. 5.1d is generally larger and has more timeout messages. Table 3.1 presents the statics of the RTT of unicast latency of Thread mesh network. The mean, maximum, minimum and standard derivation of RTT are calculated for each test case. As we can see, the mean value of RTT increases with the hops in all the cases. Besides, the LOAD case 3 and case 4 have bigger mean value in case 1 and 2. Furthermore, the maximum RTT ranges from 59 to 7304 ms due to the CoAP retransmissions. This shows that CoAP retransmissions, to some extent, increase the reliability of the network, but sacrifice the latency. The standard variation also has a wide range because of the CoAP retransmissions. The figure. 5.2 shows the details of the packet delivery ratio (PDR) of 5.2. Unicast and Reliability 27

TABLE 5.2: Statistics of the Round Trip Time (RTT)

Test 1 2 3 4 5 6 case hop hops hops hops hops hops 1 mean 28.98 49.42 74.64 94.22 120.88 150.37 max 59 84 2872 140 2739 3141 min 19 28 48 64 82 98 4.52 7.66 72.81 9.79 68.69 198.64 2 mean 29.06 54.87 88.25 95.69 117.78 139.27 max 45 2249 8873 139 206 184 min 18 35 46 64 85 103 4.9 63.91 339.39 10.19 11.88 12.65 3 mean 34.29 62.38 81.61 112.99 127.87 142.65 max 3034 2856 2677 7304 3119 243 min 16 30 54 62 89 105 122.81 142.67 87.96 231.47 124.55 17.98 4 mean 32.89 58.75 88.50 108.00 119.52 139.81 max 2837 6657 3091 3081 219 228 min 18 32 46 66 89 111 93.78 190.96 149.59 148.73 14.63 15.00

(A) (B)

FIGURE 5.2: Packet delivery ratio with the deadline 50ms, 100ms, 150ms, 200ms the latency. When the deadline is 50 ms, only the packets within 2 hops can meet the requirement. If the hops are not greater than 3, the probability of 28 Chapter 5. Result Analysis the RTT within 100ms can be up to 90%. With 6 hops, the probability of RTT less than or equal to 200 ms is near 99% in all 4 cases. These results reveal that Thread shows excellent performance in multihop mesh networks because 200 ms is usually the deadline used in applications of Wireless BA. The Fig. 5.3 shows the details of comparison among the 4 cases with respect to different hops. As we can see, the cases with load have generally larger latency than without load. But there are not big differences between the burston and the burstoff versions.

(A) (B)

(E) (F)

FIGURE 5.3: Comparison between 4 cases with respect to different hops

In conclusion, the unicast latency of Thread mesh network performs very well meeting the time deadline in BA application - 200ms. The latency is increasing as the hops increase, up to 6 hops in our test. Furthermore, the load in the network has a signiﬁcant inﬂuence on the latency, which will be investigated in the next Chapter. 5.3. Multicast and Reliability 29

5.3 Multicast and Reliability

In this section, the experimental results of the multicast latency are presented. Table. 5.3 shows the reliability result of the multicast test. There are totally 1358 multicast packets with the time interval of 2 seconds sending from the BR and 1341 messages have been received by all the nodes in the network. The reliability is 98.75% which is satisfactory for the use cases in BA, as the application level retransmission has not been considered in our test.

TABLE 5.3: Reliability of multicast

Sending packets Successful send Reliability Results 1358 1341 98.75%

Figure. 5.4 presents the CDF of TCC in the multicast latency test. 500 multicast messages have been sent with the time interval of 2 seconds. It shows that near 99% of the TCC results are within 200 ms in mesh network, with the maximum number of hops being six. The results of TCC more than 2000 ms represent the packets which are timeout.

FIGURE 5.4: CDF of TCC in multicast latency test

TABLE 5.4: Statistics of the Time for Complete Coverage (TCC)

TCC of max 6 hops mean 92.62 max 184 min 49 19

Table. 5.4 shows the statistic data for TCC in multicast test with maximum 6 hops mesh network. Here the timeout data in the test is not included 30 Chapter 5. Result Analysis as this table wants to show the patterns and features of successful transmis- sions. The maximum of TCC is 184 ms, while the minimum is 49 ms. The standard deviation is 19 ms.

5.4 Availability

FIGURE 5.5: Availability result of Thread mesh network with 38 nodes

Figure. 5.5 shows the availability test results of Thread mesh network with 38 nodes. The x axis is the time with the interval 1 hour as the probability of availability is calculated every one hour in our test. It can be seen from the graph that average availability in this Thread mesh network is close to 88%, accompanied by 6% up and down of ﬂuctuations. There are several reasons which might cause these ﬂuctuations:

The instability between the links of the nodes; • Interferences from other wireless protocols, like wireless HART, Blue- • tooth and Wi-Fi;

Packet generating rate is too high in this large mesh network, e.g., • sending the CoAP GET message nearly every 250 ms;

No retransmission mechanism used in the application layer. • Because of time limitations during the thesis work, a further investiga- tion of the availability is not present in this master thesis. However, this availability test is a promising research area for future work. There could be many interesting research and application ﬁelds. For instance, the retransmission mechanism in the APP layer should be added to guarantee the availability. Also, when installers deploy the nodes, they can use some indicators in WSN like RSSI, link quality, routing table to determine the long term availability in Thread network. 31

Chapter 6

Modeling and Validation of Latency in the Thread Mesh Network

6.1 System model of latency of multihop Thread mesh network

In this section, the system level model about the latency of Thread mesh network is proposed, considering the implementation of the Thread proto- Round&Trip&Time&analysis&modelcol, from the APP layer down to PHY layer.

Application&Layer Application&Layer Application&Layer Application&Layer

Transport& Layer(UDP) Transport& Layer(UDP) Transport& Layer(UDP) Transport& Layer(UDP)

Network&Layer(IPv6) Network&Layer(IPv6) Network&Layer(IPv6) Network&Layer(IPv6)

T2 6LoWPAN T0 6LoWPAN& (Routing) 6LoWPAN(Routing) T2 6LoWPAN T0

IEEE& 802.15.4(MAC) IEEE& 802.15.4(MAC) IEEE& 802.15.4(MAC) IEEE& 802.15.4(MAC) T1 IEEE& 802.15.4(PHY) IEEE& 802.15.4(PHY) IEEE& 802.15.4(PHY) IEEE& 802.15.4(PHY)

Source:&Border&router Active&router Active&router Destination T0:&propagation&time,&from&application&layer&to&physical&layer Sending&route Receiving&route T1:&over&the&air&time&plus&routing&time T2:&propagation&time,&from&physical&layer&to&application&layer RTT in single hop experimental test result ! Routing&protocol&:&DVRPFIGURE 6.1: System model of the latency of Thread mesh network

Average RTT THR TX: 814 us

Application Layer Application Layer Average RTT MAC TX: 5372 us

Transport Layer(UDP) Transport Layer(UDP) Average RTT PHY TX: 4328 us IPS TX IPS RX Network Layer(IPv6) Network Layer(IPv6) Average RTT OTA: 16140 us

6LoWPAN 6LoWPAN Average RTT PHY RX: 265 us ©&ABB&Group& August&6,&2016 |&Slide&5 IEEE 802.15.4(MAC) MAC RX IEEE 802.15.4(MAC) MAC TX Average RTT MAC RX: 446 us PHY TX IEEE 802.15.4(PHY) PHY RX IEEE 802.15.4(PHY) Average RTT THR RX: 540 us

OTA Average RTT TOTAL: 27908 us

FIGURE 6.2: latency of different layer in Thread network

The system level model is based on the procedures of the packet message transmission THR in TX, the PHY Thread TX, PHY mesh RX, network. MAC RX, THR Without RX time loss did of not generality, change too much. in ﬁgure. 6.1, the MAC 3-hop TX change round a triplot because procedures of the Back are- reported,off time in MAC while layer. ﬁgure. 6.2 presents the delay of different layers in Thread protocol. The source OTA includes the process time of the receivers and also changes due to the MAC TX of node is the borderreceiver router side. while the destination is end device. The round

© ABB Group July 26, 2016 | Slide 6 Chapter 6. Modeling and Validation of Latency in the Thread Mesh 32 Network trip time can be separated into two parts: the sending route and the receiving route. The sending route begins at the border router’s application layer and then go through the network layer, MAC layer and physical layer where the transceiver transmits the message. Then the packet will be in the routing path which consists of the over-the-air (OTA) time and the relay nodes’ processing time. When the packet reaches the physical layer of the destination, the destination node starts processing the packet and sending this packet from the physical layer to application layer. At this point, the sending route is finished while the receiving route begins. The destination node sends back the ACK command following the same route as sending route. Based on the description above, round trip time of the packet can be divided into three categories according to the packet propagation process. The first one is the propagation time from application layer to physical layer, denoted as T0. The second one is OTA time plus the relay nodes’ processing time T1. The third one is the propagation time from the physical layer to application layer T2. The whole RTT is defined as:

T =2 T + T +2 T . (6.1) RTT ⇥ 0 1 ⇥ 2 Now we deﬁne in the details the component of the previous equation. For T0 part, it consists of the processing time from application layer to MAC layer, denoted as IP stacks (IPS) TIPS0, the MAC layer processing time TMAC0 and the physical layer processing time TPHY0, so that:

T0 = TIPS0 + TMAC0 + TPHY0 . (6.2)

For T1, it includes the OTA time and the processing time in the relay nodes. The OTA time can be neglected as the speed of the wireless waveform in the air is as fast as light. Therefore, the T1 depends on the relay nodes’ routing time. When relay nodes are forwarding the message, the packets are first entering physical layer, MAC layer and then 6LowPAN layer where the next forwarded nodes are decided. Then forwarded messages will go through MAC layer and physical layer to transmit to the next node. Once it receives the MAC ACK back from the next relay node, the forwarding process of this node is finished. The forwarding processing time of one relay node can be defined as TROUTE:

TROUTE = TMAC2 + TPHY2 + TPHY0 + TMAC0 . (6.3)

In the Thread mesh network, we indicate by n the number of hops . The total routing time is related to n. Considering the total routing time in multihop network: T =2 (n 1) T . (6.4) 1 ⇥ ⇥ ROUTE It can be noticed that the TRTT in Eq. ( 6.1) is related to the time TPHY0, TMAC0, TIPS0, TPHY2, TMAC2, TIPS2 and the number of hops n. TPHY0, TIPS0, TPHY2, TMAC2, TTHY2 are decided by the hardware factors and the implementation of Thread protocols except TMAC0. TMAC0 is the MAC layer service time that is not ﬁxed because of exponential back-off process in the CSMA/CA mechanism. This random back-off time depends on the trafﬁc rate and the number of nodes in the network, which will be discussed 6.2. Numerical results and experimental validation 33

in the next section. Similarly, T2 also consists of the processing time of the physical layer TPHY2, MAC layer TMAC2 and the MAC to application layer time TIPS2 when receiving the messages. Therefore,

T2 = TIPS2 + TMAC2 + TPHY2 . (6.5)

6.2 Numerical results and experimental validation

In this section, the analytical model results, which show the distribution of MAC service time, are first presented by investigating the number of nodes in network and the effect of traffic conditions. Then in order to quantify the system level model, the hardware related latency is investigated. Finally, to verify the model, experimental studies are carried out, which show a good confirmation with the system level models. Details follow in the sequel.

MAC service time distribution, 6 = 0.5 MAC service time distribution, N = 10 0.1 0.1 N=2 6=0.1 0.09 0.09 N=5 6=0.3 N=10 6=0.5 0.08 N=20 0.08 6=0.7 N=30 6=0.9 0.07 N=40 0.07 N=50 0.06 0.06

0.05 0.05

probability 0.04 probability 0.04

0.03 0.03

0.02 0.02

0.01 0.01 0 0 0 10 20 30 40 50 60 0 10 20 30 40 50 60 delay(ms) delay(ms)

(A) (B)

FIGURE 6.3: MAC service time distribution. (a) shows the relationship between the probability distributions and the nodes numbers N with = 0.2. (b) shows the relationship between the the probability distributions and with N = 10.

850 5400

y = 0.9886*x + 778.7 5200 y = 33.817*x + 3315.4 840

5000 830 4800

4600 820 4400

4200 810

4000 800 physical layer delay (us) 3800 IP stacks layer delay (us)

3600 physical delay 790 data fit IP stacks layer delay 3400 data fit 0 10 20 30 40 50 60 70 780 0 10 20 30 40 50 60 70 data length (Bytes) data length (Bytes)

(A) (B)

FIGURE 6.4: experimental test of PHY layer latency (A) and IPS layer latency (B) Chapter 6. Modeling and Validation of Latency in the Thread Mesh 34 Network

6.2.1 Statistical probability distribution of MAC service time By calculating the analytical equations of the Markov chain model in the paper (Park et al., 2009b), the distribution of MAC service time TMAC0 is presented with respect to the nodes numbers N and the network traffic conditions . According to the parameters used in the Thread mesh network, the settings are as follows: m0 =5,m=4,n=3. A fixed packet length of L =7 is used in calculations. figure. 6.3 (a) shows the probability distribution of MAC service time as function of different nodes N =2, 5, 10, 20, 30, 40, 50 with given =0.5. It can be easily observed that with the increase of nodes number N, the side lobes of the distribution function increase also and the probability of low latency trapezoid area decrease. The reason is that the increase of nodes number N will heavier the network traffics and thus increase the busy channel probability ↵ and collision probability Pc will also increase. figure. 6.3 (b) presents the relationship between packet generation rate (1 ) and the probability distributions with nodes number N = 10. The heavier the traffic situation in the network, the heavier tail it has. This is because increasing traffic rate will also increase the fails in channel sens- ing and packet transmitting. It should be noticed that nodes number N has stronger influences on the probability distributions than . For N =2, probability distribution is similar to a deterministic one.

6.2.2 Latency related to hardware and software implementation In this section, the latency of other layers besides MAC layer is experimentally investigated, which are closely related to the hardware aspects and implementation of software stack. First, the hardware platform and software stack for experimental study are introduced. Second, the experimental tests are presented to understand the latency introduced by hardware and software implementation. The hardware board FRDM-KW24D512 (kw24) together with the Thread 1.0.0 preview software from NXP company (kw24) are used this paper’s experimental studies. For the software stacks, FreeRTOS (freertos) is used, which may introduced extra latency. Remind the total latency TRTT in Eq. (6.1), TPHY0, TMAC0, TIPS0, TPHY2, TMAC2, TIPS2 need to be known in order to calculate the total RT T . TMAC0 can be referred from MAC service time distribution from last section if nodes number N and traffic condition are given. The other kinds of parameters will be gained from the test bed. In the software stack, the time stamps are added to get the time interval of each layers as shown in figure. 6.2. At first, the packet length of 10 Bytes are applied in the test. The results are shown in the Table 6.1. Then packet length of 20 Bytes, 30 Bytes, 40 Bytes, 50 Bytes, 60 Bytes are tested in turns. The results show that delays of IPS TX and PHY TX are proportional to packet length. Therefore, liner regression is used to estimate the latency in IPS TX and PHY TX states, as shown in figure 6.4. Here the data length counts only the payload of application layer, e.g., CoAP’s payload. The linear regression model fits very well with the testing data in both physical layer and Thread network layer. For physical layer, the delay comes from the packet copying between micro-controller and radio transceivers 6.2. Numerical results and experimental validation 35 through serial peripheral interface (SPI), where

L T = (6.6) PHY0 vS ⇠ b ⇡ For Thread layer latency, it is decided by the copying speed inside the micro-controller in software stack implementation from application layer to network layer. Hence the delay is within 1 ms. The delay of PHY RX, MAC RX, IPS RX are constant in our testing case as the ACK length is ﬁxed, as shown in Table 6.1. The overall receiving latency is near 1ms, depending on data processing in both micro-controller and radio transceivers.

TABLE 6.1: Experimental data of the Thread latency in different layers with data length 10 Bytes

Average result of 500 test times delay(us) IPS TX 788 MAC TX 5490 PHY TX 3653 PHY RX 266 MAC RX 445 IPS RX 544

6.2.3 Experimental validation of Thread mesh network In this section, comparisons between analytical results and experimental results from Chapter. 5 are presented. Taking into account that the latency of Thread mesh network can be calculated using the formula 6.1, in multihop case, the transmitting delay in MAC layer of all nodes can be obtained using convolutions, once the probability distribution of MAC service time is known. The other kinds of delays besides MAC TX can be acquired from last section. The probability distribution of Thread mesh network and analytical model results are shown in ﬁgure. 6.5. As our system level model has not considered the application layer retransmission, the CoAP layer retransmissions are ignored. The latency model ﬁts well with the test results with respect to different hops. It can be noticed that the distribution of round-trip time is mainly decided by MAC back-off time.

6.2.4 Software tool to estimate the latency of Thread mesh network In this section, a software tool to estimate the latency of Thread mesh network is implemented in MATLAB R2015B. As the figure. 6.6 shows, the parameters N,, m, mb,m0,L,Ls,Lccan be configured according to the setup of the Thread mesh network. The right side is the figure of estimation of RTT according to the parameter configuration. It depicts the probability distribution of RTT from 1 to 6 hops. First, this tool reveals the relationship among MAC parameters and the unicast latency in multihop mesh Chapter 6. Modeling and Validation of Latency in the Thread Mesh 36 Network network. Second, latency estimation gives the distribution of RTT with different hops, which can serve as a guide for installers to deal with deployment and configuration for Thread network. 6.2. Numerical results and experimental validation 37

0.12 ana: 1 hop ana: 2 hops ana: 3 hops 0.1 ana: 4 hops ana: 5 hops analytical model ana: 6 hops

0.08

experimental data

0.06 probability

0.04

0.02

0 0 20 40 60 80 100 120 140 160 180 200 delay(ms)

(A)

0.1 ana: 1 hop ana: 2 hops 0.09 ana: 3 hops ana: 4 hops ana: 5 hops ana: 6 hops 0.08 analytical model

0.07

experimental data 0.06

0.05 probability 0.04

0.03

0.02

0.01

0 0 20 40 60 80 100 120 140 160 180 200 delay(ms)

(B)

FIGURE 6.5: Unicast latency results for 6-hop mesh network of Thread: (A) case 1 (B) case 4 Chapter 6. Modeling and Validation of Latency in the Thread Mesh 38 Network

FIGURE 6.6: Software tool to estimate the latency of Thread mesh network 39

Chapter 7

Conclusion and Future work

7.1 Conclusions of the work

At the beginning of this thesis, the related work about WSN applied in BA has been introduced. Although the landscape of standardization is still fragmented, the BA industry has reached a consensus to adopt NIP connectivity technologies in the future. The 6LoWPAN adaption layer tears down the wall for WSNs and allows them enter the IP world by incorporating the IPv6 packages in small link layer frames. Thread, which not just adopts 6LoWPAN, but also introduces many new features regarding security, reliability and low power consumption, aims at the target market of home and building automation. Later in this thesis, a thorough experimental evaluation of Thread mesh network has been carried out with respect to signal coverage, unicast and multicast latency, reliability , and availability. The signal coverage test results provide a clear picture about the communication range of the IETF IoT stacks and Thread stacks. The results show the range performance is slightly affected by the protocols but mainly decided by transmit power. The transmitted signals in our test can easily cross the hard walls and in- door barriers. The unicast latency and reliability test demonstrated that Thread multihop messages running in the network have a low RTT and PDR. Within 6 hops in the mesh network, the RTT probability is near 99% in the 4 test cases covering the low trafﬁc and heavy trafﬁc conditions. The multicast latency and reliability test also proves that Thread multicast messages that are sent in large mesh networks have a satisfying performance as regards TCC and reliability. The reliability for multicast messages is more than 98% in our test, while the TCC for 6 hops of Thread mesh network is generally within 200 ms with the probability 99%, giving a promising performance for further commercial products development. Finally, the availability test shows that nearly 88% of nodes in the network are accessible in the test with the employed methods. As the test did not consider application retransmission and is under stringent testing setting, this result is acceptable during research stage. However, in further commercial stages, the availability need be improved according to the application areas. This result also shows a further research direction in the future. A further step was took in this thesis to investigate the modeling of latency in Thread mesh network. a system level model regarding different layers for the latency of Thread mesh network is presented and validated by the experimental results. The model presents a good match with experimental test results. Finally, a friendly tool using MATLAB is developed for installers to estimate the latency of Thread mesh network. 40 Chapter 7. Conclusion and Future work

7.2 Future work

For the experimental testing part, the multicast performance under different network trafﬁc conditions can be further investigated, given multicast is a crucial feature in the Thread protocol and is widely used in BA applications. As most of our tests are carried out in local area network, web-based or cloud-based testing about unicast and multicast latency, reliability and availability are also promising research areas. For availability, adding the retransmission mechanism in the APP layer will also need to be test. For the theoretical part, modeling of multicast latency of Thread mesh network will be further investigated in our future work. Furthermore, using short term indicators in the network to predict long term availability performance will be another work to consider. For example, when installers deploy the nodes, they can use some indicators in WSN like RSSI, link quality, routing table to determine the long term availability in Thread network. 41

Bibliography

Akyol, BA et al. (2010). “A survey of wireless communications for the elec- tric power system”. In: Alliance, ZigBee (2013). ZigBee IP Specification (ZigBee Public Document 13- 002r00). Association, IEEE Standards (2011). IEEE Standard for Local and Metropolitan Area Networks— Part 15.4: Low-Rate Wireless Personal Area Networks (LR- WPANs). New York, NY, USA. Avizienis, Algirdas et al. (2004). “Basic concepts and taxonomy of dependable and secure computing”. In: IEEE transactions on dependable and secure computing 1.1, pp. 11–33. BACnet Offical Website. http://www.bacnet.org/. Accessed: 2016-08- 04. Djamaa, Badis et al. (2014). “Unicast/multicast performance in single-hop duty-cycled 6LoWPAN networks”. In: Communication Systems, Networks & Digital Signal Processing (CSNDSP), 2014 9th International Symposium on. IEEE, pp. 140–145. Farahani, S. (2011). ZigBee Wireless Networks and Transceivers. Elsevier Sci- ence. ISBN: 9780080558479. FRDM-KW24D512 Freedom Development Platform User’s Guide. http : / / www.nxp.com. Accessed: 2016-07-27. Gnawali, Omprakash and P Levis (2013). “Recommendations for Efficient Implementation of RPL”. In: Håkansson, Anne (2013). “Portal of research methods and methodologies for research projects and degree projects”. In: Proceedings of the Interna- tional Conference on Frontiers in Education: Computer Science and Computer Engineering (FECS). The Steering Committee of The World Congress in Computer Science, Computer Engineering and Applied Computing (WorldComp), p. 1. Hui, Jonathan, David Culler, and Samita Chakrabarti (2009). “6LoWPAN: Incorporating IEEE 802.15. 4 into the IP architecture”. In: IPSO Alliance White Paper 3. Hui, Jonathan and Richard Kelsey (2016). Multicast Protocol for Low-Power and Lossy Networks (MPL). Tech. rep. Hui, Jonathan and Pascal Thubert (2011). “Compression format for IPv6 datagrams over IEEE 802.15. 4-based networks”. In: Kruger, C. P. and G. P. Hancke (2014). “Implementing the Internet of Things vision in industrial wireless sensor networks”. In: 2014 12th IEEE Inter- national Conference on Industrial Informatics (INDIN), pp. 627–632. DOI: 10.1109/INDIN.2014.6945586. Laboratories, NXP (2014). IEEE 802.15.4 Stack User Guide, JN-UG-3024. UK. Levis, Philip et al. (2004). “Trickle: A self-regulating algorithm for code propagation and maintenance in wireless sensor networks”. In: Proc. of the 1st USENIX/ACM Symp. on Networked Systems Design and Implemen- tation. 42 BIBLIOGRAPHY

Liu, Yide (2012). “Wireless Sensor Network Applications in Smart Grid: Re- cent Trends and Challenges”. In: International Journal of Distributed Sen- sor Networks 2012. Low Power WiFi. http://www.wifi.org/. Accessed: 2016-08-04. Marco, P. Di et al. (2012). “Analytical Modeling of Multi-hop IEEE 802.15.4 Networks”. In: IEEE Transactions on Vehicular Technology 61.7, pp. 3191– 3208. ISSN: 0018-9545. DOI: 10.1109/TVT.2012.2201221. Mariager, Peter and J Petersen (2013). “Transmission of IPv6 Packets over DECT ultra low energy”. In: MKW2xD Data Sheet. http://cache.nxp.com/files/rf_if/doc/ data_sheet/MKW2xDxxx.pdf?pspll=1. Accessed: 2016-07-27. Montenegro, Gabriel et al. (2007). Transmission of IPv6 packets over IEEE 802.15. 4 networks. Tech. rep. Nieminen, Johanna et al. (2011). “Transmission of ipv6 packets over bluetooth low energy”. In: draft-ietf-6lowpan-btle-05, work in progress. Nixon, M. (2012). “A Comparison of WirelessHART and ISA100.11a”. In: Whitepaper, pp. 11–17. OECD (2009). “Smart Sensor Networks: Technologies and Applications for Green Growth”. In: pp. 15–17. Palattella, Maria Rita et al. (2013). “Standardized protocol stack for the internet of (important) things”. In: IEEE Communications Surveys & Tutori- als 15.3, pp. 1389–1406. Pang, Zhibo et al. (2015). “Work-in-progress: Industry-friendly and native- IP wireless communications for building automation”. In: Industrial Net- works and Intelligent Systems (INISCom), 2015 1st International Conference on. IEEE, pp. 163–167. Park, P. et al. (2009a). “A generalized Markov chain model for effective analysis of slotted IEEE 802.15.4”. In: 2009 IEEE 6th International Con- ference on Mobile Adhoc and Sensor Systems, pp. 130–139. DOI: 10.1109/ MOBHOC.2009.5337007. Park, Pangun et al. (2009b). Delay analysis of slotted IEEE 802.15. 4 with a ﬁnite retry limit and unsaturated trafﬁc. Petersen, Stig and Simon Carlsen (2011). “WirelessHART Versus ISA100.11a: The Format War Hits the Factory Floor”. In: Industrial Electronics Maga- zine, IEEE 5.4, pp. 23–34. Petrova, M. et al. (2006). “Performance Study of IEEE 802.15.4 Using Mea- surements and Simulations”. In: Wireless Communications and Networking Conference, 2006. WCNC 2006. IEEE. Vol. 1, pp. 487–492. DOI: 10.1109/ WCNC.2006.1683512. Rausand, Marvin and Arnljot Høyland (2004). System reliability theory: models, statistical methods, and applications. Vol. 396. John Wiley & Sons. Ruta, Michele et al. (2014). “KNX, a worldwide standard protocol for home and building automation: state of the art and perspectives”. In: Sauter, T. et al. (2011). “The Evolution of Factory and Building Automa- tion”. In: IEEE Industrial Electronics Magazine 5.3, pp. 35–48. ISSN: 1932- 4529. DOI: 10.1109/MIE.2011.942175. Shelby, Z et al. (2012). Constrained application protocol (CoAP), constrained resources (CoRE) working group, internet engineering task force (IETF), work in progress, draft-ietf-core-coap-13. BIBLIOGRAPHY 43

SMAC Wireless connectivity made easy. http://www.nxp.com/files/ microcontrollers/doc/support_info/BeyondBits2article16. pdf. Accessed: 2016-05-21. The Thread Group. http://threadgroup.org. Accessed: 2016-08-04. Threadgroup ofﬁcial website. http://www.threadgroup.org/. Accessed: 2016-06-27. Tripathi, J, J de Oliveira, and JP Vasseur (2012). Performance evaluation of the routing protocol for low-power and lossy networks (RPL). Tech. rep. Winter, Tim (2012). “RPL: IPv6 routing protocol for low-power and lossy networks”. In: Woo, Alec, Terence Tong, and David Culler (2003). “Taming the Underly- ing Challenges of Reliable Multihop Routing in Sensor Networks”. In: Proceedings of the 1st International Conference on Embedded Networked Sen- sor Systems. SenSys ’03. Los Angeles, California, USA: ACM, pp. 14–27. ISBN: 1-58113-707-9. DOI: 10 . 1145 / 958491 . 958494. URL: http : //doi.acm.org/10.1145/958491.958494. TRITA TRITA-EE 2016:182 ISSN 1653-5146