Experimental Study of Thread Mesh Network for Wireless ...1040491/FULLTEXT02.pdf · Experimental...

INOM EXAMENSARBETE ELEKTROTEKNIK,AVANCERAD NIVÅ, 30 HP

, STOCKHOLM SVERIGE 2016

Experimental Study of Thread Mesh Network for Wireless Building Automation Systems

DAPENG LAN

KTHSKOLAN FÖR ELEKTRO- OCH SYSTEMTEKNIK

i

KTH ROYAL INSTITUTE OF TECHNOLOGY

Abstract

Master of Science

Experimental Study of Thread Mesh Network for Wireless BuildingAutomation Systems

by Dapeng LAN

Wireless sensor network technologies have gained significant popularity inhome automation due to their scalability, system mobility, wireless connec-tivity, inexpensive and easy commissioning. Thread, a new wireless pro-tocol aiming for home automation, is proposed by Google Nest and stan-dardized by Thread Group.

This thesis presents a thorough experimental evaluation of Thread wire-less protocol with the hardware platform from NXP. The test plan, imple-mentation, and analysis of the experiments is discussed in details, includingsignal coverage, unicast and multicast latency, reliability, and availability.Furthermore, a system level model considering the delay in different layersfor the latency of Thread mesh network is presented, and validated by theexperimental results. Finally, a friendly tool was developed for installers toestimate the latency of Thread mesh network.

HTTP://WWW.KTH.COM

!!!!!!!!!

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) ThreadAmeshAnätverket.))))

iii

AcknowledgementsFirst 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-artWSN protocol - Thread. Also I would like to thank my co-supervisor, GargiBag, for her patience toward solving my confusions and her kindly encour-agement. This paper would never be accomplished without their valuableassistance and dedicated involvement. Furthermore, I would like to thankmy examiner, Carlo Fischione.

Besides, I would like to thank my research group members Eva Azoidouand Yu Liu. They gave me support during my research period and helpedme spend pleasurable life in ABB. It is difficult to mention all friends I havemet in ABB and KTH, whom I have learnt a lot of things from and offeredme unforgettable experience. Thanks to all of them.

Finally, I would like to thank my parents for giving me any kinds ofsupport substantially and spiritually throughout my studying life.

v

Contents

Abstract i

Acknowledgements iii

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Contribution of the Thesis . . . . . . . . . . . . . . . . . . . . 31.5 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Related work in Wireless Sensor Networks 52.1 From Non-IP to Native IP . . . . . . . . . . . . . . . . . . . . 52.2 Overview of the IEEE 802.15.4 standard . . . . . . . . . . . . 5

2.2.1 Non-beacon enabled IEEE 802.15.4 CSMA/CA . . . . 62.3 IETF IoT stacks . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.1 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.2 RPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3.3 CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4 Overview of Thread protocol . . . . . . . . . . . . . . . . . . 92.4.1 Protocol stacks . . . . . . . . . . . . . . . . . . . . . . 92.4.2 Device types . . . . . . . . . . . . . . . . . . . . . . . . 102.4.3 Multicast Protocol for Low power and lossy networks

(MPL) . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4.4 Comparison with other protocols . . . . . . . . . . . . 11

2.5 Other protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5.1 Zigbee . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5.2 WirelessHART and ISA100 . . . . . . . . . . . . . . . 12

3 Test plan 153.1 Signal Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2 Unicast latency and reliability . . . . . . . . . . . . . . . . . . 163.3 Multicast latency and reliability . . . . . . . . . . . . . . . . . 173.4 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Experimental Setup 194.1 Test platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2 Signal Coverage Setup . . . . . . . . . . . . . . . . . . . . . . 204.3 Unicast Latency and Reliability Setup . . . . . . . . . . . . . 204.4 Multicast Latency and Reliability Setup . . . . . . . . . . . . 234.5 Availability Test Setup . . . . . . . . . . . . . . . . . . . . . . 24

vi

5 Result Analysis 255.1 Signal Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . 255.2 Unicast and Reliability . . . . . . . . . . . . . . . . . . . . . . 265.3 Multicast and Reliability . . . . . . . . . . . . . . . . . . . . . 295.4 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6 Modeling and Validation of Latency in the Thread Mesh Network 316.1 System model of latency of multihop Thread mesh network 316.2 Numerical results and experimental validation . . . . . . . . 33

6.2.1 Statistical probability distribution of MAC service time 346.2.2 Latency related to hardware and software implemen-

tation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.2.3 Experimental validation of Thread mesh network . . 356.2.4 Software tool to estimate the latency of Thread mesh

network . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7 Conclusion and Future work 397.1 Conclusions of the work . . . . . . . . . . . . . . . . . . . . . 397.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 mech-anism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 IETF LLN protocol stack . . . . . . . . . . . . . . . . . . . . . 82.3 Thread protocol stacks. . . . . . . . . . . . . . . . . . . . . . . 102.4 Thread device types(Threadgroup official website) . . . . . . . . 10

3.1 Definition of round trip time . . . . . . . . . . . . . . . . . . . 16

4.1 Hardware platform - FRDM-KW24D512 . . . . . . . . . . . . 194.2 Signal coverage test setup . . . . . . . . . . . . . . . . . . . . 204.3 Thread mesh network topology . . . . . . . . . . . . . . . . . 204.4 Communication between laptop and border router . . . . . . 214.5 nodes placement in the building . . . . . . . . . . . . . . . . 224.6 Deployment of Nodes in the building for multicast test . . . 23

5.1 Latency result of 6 hops for 4 test cases . . . . . . . . . . . . . 265.2 Packet delivery ratio with the deadline 50ms, 100ms, 150ms,

200ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.3 Comparison between 4 cases with respect to different hops . 285.4 CDF of TCC in multicast latency test . . . . . . . . . . . . . . 295.5 Availability result of Thread mesh network with 38 nodes . . 30

6.1 System model of the latency of Thread mesh network . . . . 316.2 latency of different layer in Thread network . . . . . . . . . . 316.3 MAC service time distribution. (a) shows the relationship

between the probability distributions and the nodes numbersN with � = 0.2. (b) shows the relationship between the theprobability distributions and � with N = 10. . . . . . . . . . . 33

6.4 experimental test of PHY layer latency (A) and IPS layer la-tency (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

ix

List of Tables

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

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

4.1 Experimental setup parameters for unicast latency . . . . . . 224.2 Experimental setup parameters for multicast latency . . . . . 234.3 Experimental setup parameters for availability test . . . . . . 24

5.1 Signal coverage result (meters) . . . . . . . . . . . . . . . . . 255.2 Statistics of the Round Trip Time (RTT) . . . . . . . . . . . . . 275.3 Reliability of multicast . . . . . . . . . . . . . . . . . . . . . . 295.4 Statistics of the Time for Complete Coverage (TCC) . . . . . 29

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

xi

List of Abbreviations

6LoWPAN IPv6 over Low power Wireless Personal Area NetworksACK AcknowledgementBA Building AutomationBAS Building Automation SystemBPSK Binary Phase-Shift KeyingBR Border RouterCCA Clear Channel AssessmentCDF Cumulative Distribution FunctionCoAP Constrained Application ProtocolCSMA/CA Carrier Sense Multiple Access with Collision AvoidanceDSSS Direct Sequence Spread SpectrumED End DeviceIEEE Institute of Electrical and Electronics EngineersIETF Internet Engineering Task ForceIoT Internet of ThingsIP Internet ProtocolIPv6 Internet Protocol version 6LLNs Low-Power and Lossy NetworksMAC Media Access ControlMCU MicrocontrollerMTU Maximun Transmission UnitMTTF Mean Time To FailureMTTR Mean Time To RepairNIP Native Internet ProtocolNWK Network layerO-QPSK Offset Quadrature Phase-Shift KeyingOS Operating SystemOSI Open System InterconnectionOTA Over The AirPER Packet Error RatePDR Packet Delibery RatioPHY PhysicalPGF Probability Generation FunctionPLC Power Line CommunicationSPI Serial Peripheral InterfaceRPL IPv6 Routing Protocol for Low-Power and Lossy NetworksRSSI Received Signal Strength IndicatorRTT Round Trip TimeTX TransmitTCC Time for Complete CoverageTCP Transmission Control ProtocolTDMA Time Divesion Multiple AccessUART Universal Asychronous Receiver/Transmitter

xii

UDP User Datagram ProtocolWiBA Wireless Buildling AutomationWPANs Wireless Personal Area NetworksWSN Wireless Sensor Network

1

Chapter 1

Introduction

The first chapter describes the structure of this master thesis. In the firstsection, 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 prob-lems effectively are discussed. Finally, this chapter clarifies the overall con-tributions, most significant parts of this thesis work.

1.1 Background

Internt of Things (IoT) , commonly considered as "the next generation ofInternet" , has had a huge impact on human life. IoT, a complex cyber-physical system combining various kinds of sensors, actuators, network-ing, communication and information management technologies is reshap-ing the modern industrial systems, such as the ones in industry automa-tion control and building automations (BA). Building Automation System(BAS) is an intelligent system that controls the electrical and mechanicalsystems in the buildings, like measuring the environmental factors, keep-ing the building safe and controlling the actuators intelligently. With theadvanced development of IoT, BAS has been reshaping the future of build-ings, 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, theinstallation and upgrade of BAS are much harder than we expected. Earlytype of home automation devices communicate using wired technologieslike 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 signif-icant 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 configured nodes which cancommunicate with each other by radio technologies. Each node is typi-cally composed of a controller, a transceiver, sensor/actuators, memory andpower supply. The controller and memory implement the software stacksaiming to collect the data from sensors or to instruct the actuator. The radiotransceiver being connected to the internal or external antenna is responsi-ble for transmitting data packets. The transceiver consumes a large share ofthe 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 installa-tion cost, Wireless Building Automation (WiBA) has been applied to fill thegaps 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 yearsusing the same battery.

1.2 Problem Statement

WSN nature makes the network easy to scale to large dimensions and tomodify the node locations. However, devices are also easily interfered byother kinds of wireless technologies, which makes the performance of WSNhard to predict. Thus, before utilizing the new wireless protocol, it is sig-nificant to validate its performance to check whether the quality of serviceprovided fits the requirements of BAS. Thread, a new protocol aiming forHA, is proposed by Thread Group. Thread has the features of low energyconsumption, low latency and high reliability. However, the performancehas 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 WSNnetwork needed to be set up. Automatic tools need to be develop, with-out spending too much labors and time, which is an engineering challenge.The problem can be divided into three steps. First, design the test cases tomake sure that the experiments can effectively measure the performance ofThread network. Second, implement the test cases and perform the experi-ments. Finally, analyze the experimental results.

Due to the instability and uncertainty of WSN, it is challenge to mod-eling the behavior of WSN. In addition to the test, this thesis also presentsthe system level model of the unicast latency and develop a friendly toolfor installers with respect to multihop latency of Thread network.

1.3 Methodology

In order to select the best-suited methods, a collection of research meth-ods and methodologies is provided in (Håkansson, 2013). As the figure 1.1shows, the left side refers to the methods for quantification research whilethe right sides is for qualitative search. Moving from the left to right, theresearch methodologies change from being quantitative to qualitative.

As case studies are used in this thesis, both the quantitative and qual-itative research methodologies is used. For quantitative research, severalexperiments 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 method-ologies(Håkansson, 2013)

Also, the computational mathematics are applied to analyzed the unicastlatency of Thread mesh network. For qualitative research, the testing dataare collected and data analysis is performed. The outcomes of these twomethods 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 therespect to signal coverage, unicast and multicast latency, reliability,and availability;

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

1.5 Outline

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

5

Chapter 2

Related work in WirelessSensor Networks

2.1 From Non-IP to Native IP

Due to the interoperability challenges during system integration of differ-ent devices and value-added services from various suppliers, the supportof Internet Protocol (IP), the so-called Native IP (NIP), in lightweight sensordevices is a promising direction for the communication technologies of BAsystems (Pang et al., 2015). NIP means the communication protocol appliesIETF IPv4 or IPv6 between its Data Link Layer and Network Layer, andthus it can support IP-based upper layer protocols and can be integratedinto IP-based systems without heavy protocol translation or networkinggateway. NIP technologies also allow the BA industry to benefit from thefast innovations in Internet domain which has been developed in the past30 years. In a piratical scenario, the efforts toward transforming Non-IP tonative IP technologies have been clearly observed in many established BAcommunication standards, both in wire and wireless, e.g. KNX has releasedthe KNXnet/IP(Ruta et al., 2014), BACnet has released BACnet/IP(BACnetOffical Website), Zigbee has released Zigbee/IP(Alliance, 2013), DECT ULEis developing the 6LoWPAN-over-ULE(Mariager and Petersen, 2013), andBluetooth is developing the 6LoWPAN-over-BLE(Nieminen et al., 2011).Furthermore, some WSN standards have already adopted the NIP con-nectivity, e.g. IEEE 802.11ah Low Power WiFi(Low Power WiFi), ThreadGroup(The Thread Group), and the IETF IoT stacks (6LowPAN, RPL, CoAP)(Palattella et al., 2013). Although the landscape of standardization is stillfragmented, the BA industry has reached a consensus to adopt NIP con-nectivity technologies in the future.

2.2 Overview of the IEEE 802.15.4 standard

The IEEE 802.15.4 is a wireless standard, defining 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) forthe carrier sense multiple access with collision avoidance (CSMA/CA) anddata transmission and reception among other things(Association, 2011). Itcan operate in many different frequencies but one of the most commonlyused worldwide is the 2.4 GHz band, which consists of 16 available chan-nels, and it employs the direct sequence spread spectrum (DSSS) techniquewhich 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 2000kchip/s. There is also the 868 MHz PHY that is commonly used in Europeand for this frequency there is only one available channel. It uses binaryphase-shift keying (BPSK) for the modulation, the bit rate 20 Kbps and thechip rate is 300 kbit/s (Association, 2011).

There are several possible ways of implementing this standard, it hasfor example one beacon-enabled mode and one non beacon-enabled modedepending 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 ofbeacons (if the device is an access point), device security, employing chan-nel access methods and enabling a reliable link between peers and otherthings. The channel access method that is used is CSMA-CA. (Association,2011)

There are several security measures implemented in the 802.15.4 as apart of the MAC layer. There is a choice between an unsecured implemen-tation and a secure implementation. The unsecured mode contains no se-curity measures whatsoever and is therefore not highly recommended. Thesecure mode has the functions: access control, data confidentiality or en-cryption, data authenticity or integrity and replay protection or sequentialfreshness.(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 whichis also used in Thread protocol. Figure. 2.1 depicts the flowchart of unslot-ted IEEE 802.15.4 CSMA/CA channel access mechanism. Upon transmit-ting packets, MAC layer performs the following steps (initialize retransmis-sion 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 inthe range [0, 2BE�1] in order to avoid collision. The backoff time unitis 20Ts with Ts = 16µs.

2. Perform Clear Chanel Assessment (CCA) to check if the channel isbusy or idle. If the channel is idle, it goes to the step 4, otherwise itgoes 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 NBis less than macMaxCSMABackoffs , the algorithm returns to step1. Otherwise, the algorithm terminates with a channel access failure.

4. Idle channel: the MAC layer sends out the packet and waits for theACK. If ACK is received within maximum macAckWaitDuration,the packet is successfully sent. Otherwise, the packet has collidedand needs to be retransmitted. If R excesses macMaxFrameRetries,the algorithm terminates with collision fail and the packet is discard.Otherwise the algorithm initializes the NB and BE again and returnsto step 1.

2.3. IETF IoT stacks 7

FIGURE 2.1: The unslotted IEEE 802.15.4 CSMA/CA chan-nel access mechanism

2.3 IETF IoT stacks

In the past few years, IETF has established many working groups towardsthe 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 fit together. Currently this entireLLN stack protocol is available in Contiki OS. IEEE 802.15.4 standards havebeen introduced in the last sections, therefore, the following sections willdescribe the standards of 6LoWPAN, RPL and CoAP.

2.3.1 6LoWPAN

IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) is anadaption layer that allows sending IPv6 packets within small link layerframes(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 packetswithin MTU (1280bytes) can be easily send as one frame. However, IEEE802.15.4 has maximum 127 bytes packet size at the PHY layer while as lowas 88 bytes in MAC layer payload. In this situation, 6LoWPAN can act asan adaption layer between IPv6 network layer and 802.15.4 link layer byfragmenting the IPv6 packets at the sender and reassembling them at the


Protocol stacks for IETF IoT

Application (CoAP)

Transport(UDP)

Network(IPv6 with RPL)

Adaption(6LoWPAN)

IEEE 802.15.4 MAC

IEEE 802.15.4 PHY

Protocol stacks for Thread

CoAP/HTTP

UDP

IP Routing

6LoWPAN

IEEE 802.15.4 MAC

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 compressioncan be found in RFC4944 (Montenegro et al., 2007) and RFC6282 (Hui andThubert, 2011).

An other significant usage of 6LoWPAN layer is to provide link layerpacket forwarding. It provides an efficient and low-overhead mechanismto forward multihop packets in mesh networks. Thread uses IP layer rout-ing and link layer packet forwarding, thus avoiding parsing the packets tonetwork layer. In addition, Thread utilizes the MAC layer short address(16-bit length) to further reduce th information bits need to be sent overthe air. In this way, processing cycles and power consumption are reducedwhile still using the IP based routing protocols.

By the use of IP-based protocol, HA applications can increase interop-erability the other IP technologies and value-added service from differentsuppliers.

2.3.2 RPL

In 2008, a new Working Group Routing over Low power and Lossy net-works (ROLL) was founded by IETF to standardized the IPv6 based routingsolution 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 specifications give a detailed information aboutthe routing behavior, packet formats and so on.

A tree-like topology is created in an RPL network and every ROL in-stance has at least one RPL Destination-Oriented Directed Acyclic Graph(DODAG). Every DODAG has only one root and several leaf nodes. In RPLnetworks, DODAG Information Obeject (DIO) and Destination Advertise-ment Object (DAO) messages are used periodically to form and maintainthe topologies. If there is one node fail in the network, RPL can immedi-ately switch to another route. In this way, the network is kept stable. Bothupward and downward directions are supported in RPL networks via sin-gle or multihop packets. Furthermore, RPL has the mechanism to preventthe occurrence of routing loops in the occasion of node failures and packetlosses.

2.4. Overview of Thread protocol 9

RPL is able to meet different network requirements by choosing the de-signs and configuring the parameters. Recommendations for Efficient Im-plementation of RPL (draft-gnawali-roll-rplrecommendations-04) (Gnawaliand Levis, 2013) describes various design choices and parameters whenusing 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 differentuse case : a small outdoor deployment for BA and a large-scale network forsmart 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 utilizeRESTful web services for resource constrained embedded devices. Theseworks 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. CoAPhas a much lower header overhead and parsing complexity than HTTP,e.g. it just uses four-bytes base binary header. Furthermore, CoAP hasadopted many similar HTTP patterns and features, such as URIs and re-source abstraction. By using URIs, CoAP is able to easily communicate withWorld Wide Web (WWW). However, CoAP just uses UDP protocol ratherthan 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 ofthe WSN. Confirmable (CON) messages can be used in the client to ask forthe ACKs from destination nodes. If the waiting time in sending node ex-pires and ACK is still missing, the sender will retransmit the CON messagewithin the maximum retransmission times. The mechanisms of retransmis-sion 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 July2014 by Google Nest, ARM, Samsung, and some other companies (The ThreadGroup). The Thread protocol combines the best parts of several standardsto achieve a great performance aiming at BA applications.

As the figure 2.3 shows, Thread has not standardized the applicationlayer, which provides the supplier with the freedom to use proper applica-tion layers according to their needs. The feature supporting the IP allowsThread easily to interconnect with other IP-based mobile devices. As forthe network layer (NWK) in Thread, UDP is used on top of IP routing and6LoWPAN. In MAC and PHY layer, Thread uses the IEEE 802.15.4 wirelessspecification, supporting mesh network with a maximum speed of 250kbpsin the 2.4 GHz band(The Thread Group).


4

Figure 1. Overview of Thread Stack

IEEE 802.15.4 This standard is based on the IEEE 802.15.4 [IEEE802154] PHY (Physical) and MAC (Media Access Control) layers operating 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.

The 802.15.4 MAC 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 communications between adjacent devices. MAC layer encryption and integrity protection is used on messages based on keys established and configured by the higher layers of the software stack. The network layer builds on these underlying mechanisms to provide reliable end-to-end communications in the network.

No Single Point of Failure In a system 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

FIGURE 2.3: Thread protocol stacks.

2.4.2 Device types

• Devices join as Router Eligible or End Device

• Router Eligible: Can become Routers if needed

• First router on network becomes Leader

• Leader: Makes decisions within network

• End Devices: Route through parent

• Can be “sleepy” to reduce power consumption

Flexible: Simplified Device Types

FIGURE 2.4: Thread device types(Threadgroup official web-site)

Figure. 2.4 shows the device types defined in Thread network: Borderrouters (BR), routers, router-eligible end devices (REED) and sleepy enddevices (ED).

• BR is a specific router which can connect IEEE 802.15.4 networks toother physical networks like Wi-Fi or Ethernet. BR also provides ser-vices for the devices in the Thread mesh network. There can be sev-eral BRs in the network. A BR can become leader if it is the first routerin the network.

2.4. Overview of Thread protocol 11

• Routers provide routing services for devices in the network. Routesalso provide joining and security services for devices that want to jointhe network. Routers can become leader if they are the first router inthe network.

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

• Sleepy ED are host devices. They can not forward messages and onlycommunicate 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 issignificant for applications in home automations, e.g. switch on/ off the abunch of lights almost simultaneously. Multicast Protocol for Low powerand lossy networks (MPL) is proposed as an IP standards intended for wire-less mesh network(Hui and Kelsey, 2016).

MPL provides IPv6 multicast forwarding in constrained networks andavoids the maintain the multicast routing topology. Two execution modes,reactive and proactive are specified in MPL and Thread just uses proactivemode.

MPL algorithm is developed from the Trikle algorithm (Levis et al.,2004). Trikle algorithm is used to spread operational network values to thedistributed network by minimizing the load of the network. By using Triklealgorithm, constrained devices only need small, constant state to dissemi-nate the multicast message. What’s more, MPL also aware the density of thenetwork 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 ad-vantages, as shown in the table 2.1. Here are some features of Thread meshnetwork:

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

• IP based protocol : The support of IP increases the interoperabilitywith other devices. All the devices that support IP can exchange in-formation smoothly, making it easy for users as they do not need toworry about the problem of interoperability.

• Not single point of failure : Thread is no need of a coordinator and itsupports self-healing. Some devices have a critical role in the homes,like regulating the power off/on. It is crucial to provide stable ser-vices without failures.


TABLE 2.1: Thread compare with other protocols

function WiFi ZigbeePRO

ZigbeeIP-SE2.0

Z-Wave Thread

Low Power Con-sumption

7 3 7 3 3

Mesh networksupport

7 3 3 7limited 3

Support for IPv6 7 7 7 7 3interoperability 3 7 Not

clear7limited 3

Open Standard 3 3 3 7 3

• Security : Thread networks use a smart phone era authentication schemeand AES encryption to close security holes that exist in other wirelessprotocol. Thread is using IEEE 802.15.4 encryption and authenticationand 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 vari-ous sensors and additional apparatus in the customers’ local area network(OECD, 2009). ZigBee is accompanied by a low cost of implementation (lessthan 3$ per node), highly satisfactory scalability levels (64 000 nodes witha single coordinator) and a dependable coverage of 100m. ZigBee systemspossess additional appealing features, for instance, adjustable timelinesswhich can be acquired at the expense of higher power consumption andsufficient security, if compared to other standards (Liu, 2012). Its low datarate architecture of 250Kbps might be regarded as a con, however, the rateis more than adequate for the target applications.

2.5.2 WirelessHART and ISA100

WIRELESSHART and ISA100 are two competing but equally competentstandards in the industry of process automation and manufacturing. Inspite of the fact that the two standards have their own distinct technicalfeatures, they bear a resemblance in their rudimentary communication pa-rameters, for example, they both allow a data rate up to 250 Kbps and withthe maximum transmission power of 10 mW, the transmission range is ex-tended to reach 100 meters of coverage (Liu, 2012). Both standards deploya combination of DSSS and frequency-hopping spread spectrum (FHSS) asmodulation technique which is a slight modification of the modulation thattakes 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 setdue to network performance degradation after some point (Petersen andCarlsen, 2011). The channel access method implemented, in both cases, istime 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 sensornode failures (Akyol et al., 2010). ISA100 is robust in the matter of interfer-ence and it additionally utilizes congestion notifications in the presence ofoverloaded networks (Nixon, 2012).

15

Chapter 3

Test plan

This chapter introduces test case designs which reveal the performance ofThread network. Four test cases is proposed in order to evaluate the net-work quality with latest hardware platform and cutting-edge of softwareprotocols. The performance metrics of signal coverage, unicast latency andreliability, multicast latency and reliability, and availability of Thread net-work 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 intothree regions according to packet error rate (PER): effective region (PERconsistently < 10%), poor region (PER consistently > 90%) and transitionalregion (anything in between can be observed, large variation for nodes atsame distance). Although the signal coverage can be calculated by signaltheory, it is not sufficient in the real case building. The real signal coverageis largely influenced by transmit power and the surroundings. Hence, thereal case study is performed in order to measure the signal coverage.

Another purpose of this test is to compare the signal coverage perfor-mance with IETF IoT protocol which is also based on IEEE 802.15.4. Eventhough several protocols operate at the same frequency 2.4GHz and are alsobased on IEEE 802.15.4, the communication range may varies with respectto different software stack implementations and hardware platforms. Thissignal coverage test is divided into four categories by different softwarestack 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 first two test casesare applied in the hardware platform KW24D512 from NXP company. Sim-ple Media Controller (SMAC) is a small base code provided by NXP com-pany, offering communications and test applications based on the 802.15.4compliant 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 MAClayer retransmission. The second test case implements the whole Threadprotocol containing more layers and different headers. In this group, MAClayer 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 thirdgroup, the sender sends the standard IEEE 802.15.4 packets without pay-load. In the fourth group, the Contiki network protocol is used to send the6LoWPAN packet to the receiver using round-trip packet. Note that the firstand third groups use the receivers to display the reception messages whilethe 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 applicationsin 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 IoTstacks based on TinyOS Blip 2.0 IP and TinyRPL with respect to differenttopologies in the mesh network. The work in (Djamaa et al., 2014) has inves-tigated the unicast and multicast latency in single hop duty-cycled 6LoW-PAN networks using Contiki. However, there are no related researches onexperimental studies of Thread protocol. This work is the first attempt toexperimentally evaluates the latency and reliability of Thread network. Inorder to measure the unicast latency, a multihop mesh network is set upbased on our test platform. Round trip time (RTT) is used to indicate theunicast latency of the network. RTT is defined as the time duration fromthe border router sending out a message in the application layer (e.g. CoAPrequest ) 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 designed as follows:

TC1 BurstOff-Load0: to simulate the typical case in practice. The time interval between each round of test is 500ms, which means BR delays sending the next test packet for 500ms after the previous round of test is finished. There is no extra load in the network.

TC2 BurstOff-Load0.2: to simulate the heavy load case. The time interval of each round of test is 500ms, which means BR delays sending the nest test packet for 500ms after the previous round of test is finished. Each device sends CoAP GET message to a randomly selected device every 5s and waits for CoAP ACK message.

TC3 BurstOn-Load0: to simulate the medium heavy load case. The time interval between each round of test is 0, which means BR sends test packet immediately after the previous round of test is finished. There is no extra load in the network.

TC4 BurstOn-Load0.2: to simulate the very heavy load case. The time interval between each round of test is 0, which means BR sends test packet immediately after the previous round of test is finished. Each device sends CoAP GET message to a randomly selected device every 5s and waits for CoAP ACK message.

C. Definition of Evaluation Criteria

• RTT (Round Trip Time): the time duration from BR sends out a test CoAP request until receiving a CoAP response or timeout. RTT is calculated by BR and counted per System Tick of the BR. More details are shown in Fig.4. RTT is the measurement for latency in this test.

• CDF (Cumulative Distribution Function): CDF is used to analyze the statistical distribution of the RTT to give more insight.

CDFRTT (t) = P (RTT t) (1) The right-hand side represents the percentage of the test CoAP requests that get responded before a certain time t among the entire test CoAP requests.

• PDR-by-Deadline (Packet Delivery Ratio): According to different user cases, there exist different criteria of deadlines to judge if a packet is delivered successfully. PDR represents the percentage of the test CoAP requests that get responded before a predefined time t among the entire test CoAP requests. For example, in our case, the latency deadline for delay-sensitive user case is 200ms. So the PDR-by-200ms is:

PDR200ms = P (RTT ) (2)

D. Latency

Fig. 6 shows the CDF of the RTT for different test cases. It can be seen that as the number of hops increases, the probability of getting the deadlines is decreasing whatever the test case is. Comparing the load case and no load case, it is easy to find that the performance is degraded with extra traffic 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 can be seen from the curves that for 1-hop and 2-hop devices, the probability of achieving 200ms deadline is always higher than 0.9 in all of the test cases. However, for 3-hop and 4-hop devices, even in TC1 the light load case, the probability is around 0.7 and 0.25 respectively. In other 3 test cases, the probability is even lower, almost around 0.1. The performance for more than 2-hop devices is extremely unfavorable for delay-sensitive cases. There is also a common characteristic of all of the curves, which is called Stair Effect. It will be discussed further later.

Fig. 5. Deployment for the nodes in the building

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

Devices with different number of hops FIGURE 3.1: Definition of round trip time

According to the piratical traffic scenario, four test cases are going tobe implemented. The first one is a typical case in practice: no added loadin the network with packets interval time 0.5s. The other three test casesare medium, heavy and very heavy load cases based on the traffic load andpackets interval time. Details are shown in table 3.1.

3.3. Multicast latency and reliability 17

TABLE 3.1: Unicast latency test plans

No. Name Test Packet Added Load Practicalscenario

1 burstoff-load0

BR sends the next testpacket (CoAP request)500ms after the previ-ous round of test isfinished (request is re-sponded or timeout)

No Typicalcase inpractice

2 burstoff-load0.2

Same as above Every devicesends CoAPrequest to a ran-domly chosendevice per 5seconds

Heavy loadcases

3 burston-load0

Burst mode, BR sendsthe next test packet(CoAP request) imme-diately after the pre-vious round of test isfinished (request is re-sponded or timeout)

No Mediumload cases

4 burston-load0.2

Same as above Every devicesends CoAPrequest to a ran-domly chosendevice per 5seconds

Very heavyload cases

TABLE 3.2: Multicast latency test plans

No. Name Test Plan

1 Reliability Send a large amount of multicastmessages from BR and check howmany messages are successfully re-ceived by the nodes in the network

2 TCC Send a large amount of multicastmessages from BR and count thetime for complete coverage of thenetwork of each multicast message

3.3 Multicast latency and reliability

Multicast function plays an important role in the applications of BA whenit comes to large area control in the buildings, e.g., controlling an area ofsensors or actuators spontaneously with only one switch. Hence, it is nec-essary to figure 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 performmulticast latency and reliability test. Time for complete coverage (TCC) isdefined to evaluate the multicast performance of Thread network. TCCmeans the time duration from the BR sending the multicast message untilall nodes in the network have successfully received by this multicast mes-sage.

3.4 Availability

The applications in BA generally demand stringent availability require-ments, since faults may lead to malfunctions of the systems, which cancause economics losses or human injuries. In this context, faults can be clas-sified as transient or permanent(Avizienis et al., 2004). Transient faults arecaused by noise or electromagnetic interferences affecting the links betweencommunications. Permanent faults are caused by the hardware malfunc-tions causing the devices to permanently fail. This test is mainly focusedon transient faults.

The availability is defined as the probability of a component/device isworking correctly during a period of time. We can define availability A as(Rausand and Høyland, 2004):

A =MTTF

MTTF +MTTR

(3.1)

MTTF means the mean time to failure while MTTR represents themean time to repair. In this test, a large network is established to evaluatethe availability of Thread mesh network. The set up of the test is introducedin the next chapter.

19

Chapter 4

Experimental Setup

4.1 Test platform1 FeaturesThis section provides a simplified block diagram and highlights the device features.

1.1 Block diagram

Core

ARM® CortexTM –M4 50 MHz

Debug Interfaces

Interrupt Controller

DSP

System Memories RF Transceiver

Internal and External

Watchdogs

DMA

Low‐Leakage Wake‐up Unit

Program Flash (up to 512 KB)

FlexNVM 64 KB

4 KB FlexRAM MKW21D256 only

SRAM (up to 64 KB)

IEEE 802.15.4 2006 2.4 GHz

Antenna Diversity

32 MHz OSC

Dual PAN ID

SPI

Clocks

Phase‐Locked Loop

Communication Interfaces

I2C USB On‐the‐Go (HS)

Low/High Frequency Oscillators

UART (ISO 7816)

USB Device Charger Detect

(DCD)

Internal Reference

Clocks

SPI USB Voltage Regulator

Frequency Locked Loop

Timers

FlexTimer

Periodic Interrupt Timers

Low‐Power Timer

Programmable Delay Block

Independent Real‐Time

Clock (RTC)

Analog

16‐bit ADC

High‐Speed Comparator

with 6‐bit DAC

Security and Integrity

Cyclic Redundancy Check (CRC)

Cryptography Authentication

Unit

Random Number Generator

Tamper Detect

Standard Feature Optional

Figure 1. MKW2xD simplified block diagram

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

Features

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

NXP Semiconductors

(A) MKW2xD simplified block diagram

Freedom Development Board FRDM-KW24D512 User’s Guide, Rev. 1, 05/2016

NXP Semiconductors 5

FRDM-KW24D512 Overview and Description

— Programmable output power from -35 dBm to +8 dBm at the SMA connector, no trap— Receiver sensitivity: -102 dBm, typical (@1% PER for 20 byte payload packet)

• Integrated PCB inverted F-type antenna and SMA RF port• Selectable power sources• 32 MHz reference oscillator• 32 kHz clock oscillator• 2.4 GHz frequency operation (ISM Band)• External serial flash for over-the-air programming (OTAP) support• Integrated open-standard serial and debug interface (OpenSDA)• Cortex 10-pin (0.05 inches) SWD debug port for target MCU• Cortex 10-pin (0.05 inches) JTAG port for OpenSDA updates• 1 RGB LED indicator• 1 Blue LED indicator• 4 Push button switches• FXOS8700 Combo Sensor

Figure 2 shows the main platform features and I/O headers for the FRDM-KW24D512 platform.

Figure 2. FRDM-KW24D512 components and I/O headers

(B) FRDM-KW24D512 components and I/Oheaders

FIGURE 4.1: Hardware platform - FRDM-KW24D512(MKW2xD Data Sheet)(FRDM-KW24D512 Freedom Development Platform

User’s Guide)

Figure. 4.1 shows the hardware platform - FRDM-KW24D512 used inour experimental test. FRDM-KW24D512 is a development platform basedon MKW24D512 MCU and supports various wireless protocols like Thread,ZigBee Pro, 802.15.4 MAC and IPv6/6loWPAN. The components and I/Oheaders on FRDM-KW24D512 board are shown in the figure. 4.1b.

20 Chapter 4. Experimental Setup

MKW24D512 consists of a low power 2.4Ghz IEEE 802.15.4 compliantradio 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 homeand building automation like meters, gateways, lighting control, HVACand security. The system simplified block diagram of MKW24D512 is pre-sented 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 figure represents the sender placed on the office desk,which implemented the software stack that needs to be test. The red dotrepresents the receiver that moves along the corridor.

Building 206 Floor 3 Building 207 Floor 3 Building 208 Floor 3Scale 1:200

5m10m

sender

receiver

FIGURE 4.2: Signal coverage test setup

When the test program begins, the sender sends the packets continu-ously to the receiver. While at the same time, the receiver is gradually mov-ing to the end of corridor, away from the sender. In this way, the RSSI andPDR 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 thatthis method of calculation contains small error deviations but it is accept-able as only the rough range needs to be obtained. Then the Tx power isaltered for subsequent test.

4.3 Unicast Latency and Reliability Setup

BA DeviceBA Device

BA DeviceBA Device

BA DeviceBA Device

UART

BA DeviceBA Device

BA DeviceBA Device

BA DeviceBA Device

IPv6

Native-IP based BASParent Links (mesh network)

WindowsPC

BA Gateway BA Gateway

BA DeviceBA Device

BA DeviceBA Device

...

...

...BA DeviceBA Device

Parent links (topology)

Test packets

Test commands and result

Added load traffic

BA DeviceBA 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 consistsof 23 FRDM-KW24D512 hardware boards. As the figure 4.3 shows, there isone node, the BA gateway, acting as BR being connected to the Windowsdesktop. The other 22 nodes are separately deployed in the buildings to setup the local Thread mesh network. As the right side of the figure shows, theboards are connected to a mobile power bank and put inside an engineeringplastic box to guarantee the safety in the building. The red lines in the figurepresent the testing packets. The red dash lines represent the communicationbetween the laptop and BR, which is discussed in the next paragraph. Thegreen 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 borderrouter. The source codes of Thread protocol stacks are implemented in IAR7.5 EWARM and the compiled file is downloaded into the KW24D boardthrough USB port. After that, KW24D board connects to the laptop by itstwo USB ports. One of them is used as a connectivity shell, where the PCcan send the testing command to BR and collect the RTT results back toPC to further process. The other USB port connects to a Remote NetworkDriver Interface Specification (RNDIS) that is a Microsoft proprietary pro-tocol used mostly on top of USB. It provides a virtual Ethernet link to mostversions of the Windows and Linux operating systems. In this way, the IPv6packets 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 trafficinformation.

IP Based DevicesIP Based DevicesIP Based Devices

Thread Border Router Thread SnifferKW24D USB-

KW24D

Connectivity Shell

USB Serial Port

Python serial Kinetis Protocol

Analyzer Adapter

IAR 7.5 EWARM

KW24D

RNDIS

Remote Network Driver Interface Specification (RNDIS) 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.

Web Brower Coap

Wireshark

FIGURE 4.4: Communication between laptop and borderrouter

Figure 4.5 shows the deployment of nodes in different floors on thebuildings, setting up a multi-hop mesh network. Each node has an ID from0 to 22. Node 0 is the BR where sending the RTT packets. Nodes 1 to 12are the active routers, while nodes 13 to 22 are the ED. In the graph, thered circle in the third floor denotes the Thread BR, the root of the mesh


network, connecting to our desktop computer. Other nodes are spreadingin the building from basement to third floor, mainly in the meeting rooms,lounges and corridors. The deployment of nodes is close to real networkconditions used in BAs. The different colors mean the nodes are placedat different floors and the maximum number of hops in the network are 6hops.

BR

04

Building 206 Floor 3 Building 207 Floor 3 Building 208 Floor 3

0105

14

13

06

02

03

0708

11

09

10

1215

16 17

Floor 3

Border RouterFloor 3

COAP ServerFloor 4

Floor 2Floor 1Floor -1

2221

20

19

18

Router:1-12End Node: 13-22

5mScale 1:200

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, likeWi-Fi. When the test begins, BR starts sending CoAP GET messages to eachnode from node 1 to 22. The BR uses its hardware clock to calculate thetime interval between sending the message and receiving the ACK. TotallyBR sends 300 packets to each node and records how many hops to reachfo each node. All the RTT data is divided into 6 groups according to thenumber of hops. For each hop, the cumulative distribution function (CDF)curves are drew to present the RTT. When traffic mode is on, the BR sendsLOAD commands to all the nodes in the network. Then the nodes start tosend 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 la-tency

Parameters Value

Platform FRDM-KW24D512

Channel 25

Transmit Power 5 dBm

CoAP Max Retransmission 4

CoAP ACK Timeout 2000 ms

RTT packet number for eachnode

300

Packet length CoAP GET: 10 Bytes at APPlayer, 73 Bytes at PHY layerCoAP ACK: 20 Bytes at APPlayer, 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 multicasttest. In the third floor, node 0 is the BR sending the multicast messages.The connection between the BR and laptop remains the same in figure. 4.4.Nodes 1 to 17 are the active routers , while nodes 18 to 37 are the EDs. Allof the nodes are deployed in the building’s meeting room, corridors andlounges, simulating the practical use cases.

Scale 1:200

4

Building 207 Floor 3 Building 208 Floor 3

1

5

9

6

28

122

23

Active Routers: 1-12End Devices: 18-32

BR0

10

7

8

311

21

24

27

29

22

26

25

30

31

32

FLOOR 3

20

19

18

5m10m

Floor 3

Floor 4

13

14

37

Active Routers: 13-17End Devices: 33-37

BR0

15

16

17

33

35

3634

FLOOR 4

Scale 1:2005m10m

FIGURE 4.6: Deployment of Nodes in the building for mul-ticast test

The experimental setup parameters for multicast latency are shown intable. 4.2. Note that the CoAP retransmission is not used in multicast situ-ation.

TABLE 4.2: Experimental setup parameters for multicast la-tency

Parameters Value


Channel 25

Address Muticast


CoAP Retransmission No

Packet length CoAP GET: 10 Bytes at APPlayer, 73 Bytes at PHY layer


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 figure. 4.6. Theparameters used in the test are shown in Table. 4.3. The is no CoAP re-transmission during the test.

TABLE 4.3: Experimental setup parameters for availabilitytest

Parameters Value


Channel 25

MAC CSMA/CA


CoAP Retransmission No

Packet length CoAP GET: 10 Bytes at APPlayer, 73 Bytes at PHY layer

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

25

Chapter 5

Result Analysis

5.1 Signal Coverage

This section presents the test results of signal coverage. Table 5.1 shows thestatic result. As can be seen in the table, Tx power has a significant impacton the signal coverage. The larger the Tx power, the longer the signal cov-erage distance. Besides, CC2655 generally has a better performance thanKW24D irrespective of the software protocol. Here the dominant factor isthe hardware platform. When it comes to the KW24D platform, SMAC out-performs the Thread protocol in general. The reason maybe SMAC is morelightweight than Thread. Also SMAC is tested using single trip messagewhile Thread uses the round trip packets. For the round trip packets, themessage has more chance to collide over the air. For the CC2650 platform,lightweight protocol 802.15.4 also beats 6LoWPAN protocol. The reason issimilar to the platform KW24D. Another crucial factor is the wall betweenthe sender and receiver. When there are more floors between the sensorsand the receivers, the horizon distance decreases dramatically. This resultprovides fundamental data to set up the mesh network in the followingsection.

TABLE 5.1: Signal coverage result (meters)

Transmitpower(dBm)

Floor KW24DSMAC

KW24DThread

CC2650802.15.4

CC26506lowPAN

3 C 44.5 36.8 66.3 60.5B 32.3 32.3 34.0 28.7K 8.5 7.3 12.3 10.3

-3 C 34.1 28.6 37.3 35.2B 20.0 17.5 24.5 23.5K NO NO NO NO

-9 C 25.0 25.0 28.3 28.3B 13.3 10.0 16.3 1.1K NO NO NO NO

26 Chapter 5. Result Analysis

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

(C) burston-load0.2 (D) burstoff-load0.2

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. Thetests are performed in a very complex building environment having the in-terference 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 afterthe 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 testcases mentioned in Chapter 4. In general, RTT increases with the numberof 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 CoAPretransmissions. If the results are larger than 10 seconds, it means theseCoAP 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 largerand has more timeout messages.

Table 3.1 presents the statics of the RTT of unicast latency of Threadmesh network. The mean, maximum, minimum and standard derivation ofRTT are calculated for each test case. As we can see, the mean value of RTTincreases with the hops in all the cases. Besides, the LOAD case 3 and case4 have bigger mean value in case 1 and 2. Furthermore, the maximum RTTranges from 59 to 7304 ms due to the CoAP retransmissions. This showsthat CoAP retransmissions, to some extent, increase the reliability of thenetwork, but sacrifice the latency. The standard variation also has a widerange 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)

Testcase

1hop

2hops

3hops

4hops

5hops

6hops

1 mean 28.98 49.42 74.64 94.22 120.88 150.37max 59 84 2872 140 2739 3141min 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.27max 45 2249 8873 139 206 184min 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.65max 3034 2856 2677 7304 3119 243min 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.81max 2837 6657 3091 3081 219 228min 18 32 46 66 89 111� 93.78 190.96 149.59 148.73 14.63 15.00

(A) (B)

(C) (D)

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 canmeet the requirement. If the hops are not greater than 3, the probability of


the RTT within 100ms can be up to 90%. With 6 hops, the probability ofRTT less than or equal to 200 ms is near 99% in all 4 cases. These results re-veal that Thread shows excellent performance in multihop mesh networksbecause 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 withrespect to different hops. As we can see, the cases with load have generallylarger latency than without load. But there are not big differences betweenthe burston and the burstoff versions.

(A) (B)

(C) (D)

(E) (F)

FIGURE 5.3: Comparison between 4 cases with respect todifferent hops

In conclusion, the unicast latency of Thread mesh network performsvery well meeting the time deadline in BA application - 200ms. The latencyis increasing as the hops increase, up to 6 hops in our test. Furthermore, theload in the network has a significant influence on the latency, which will beinvestigated 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 pre-sented. Table. 5.3 shows the reliability result of the multicast test. There aretotally 1358 multicast packets with the time interval of 2 seconds sendingfrom the BR and 1341 messages have been received by all the nodes in thenetwork. The reliability is 98.75% which is satisfactory for the use cases inBA, as the application level retransmission has not been considered in ourtest.

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. 500multicast messages have been sent with the time interval of 2 seconds. Itshows 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 than2000 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.62max 184min 49� 19

Table. 5.4 shows the statistic data for TCC in multicast test with maxi-mum 6 hops mesh network. Here the timeout data in the test is not included


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. Thestandard deviation is 19 ms.

5.4 Availability

FIGURE 5.5: Availability result of Thread mesh networkwith 38 nodes

Figure. 5.5 shows the availability test results of Thread mesh networkwith 38 nodes. The x axis is the time with the interval 1 hour as the proba-bility of availability is calculated every one hour in our test. It can be seenfrom the graph that average availability in this Thread mesh network isclose to 88%, accompanied by 6% up and down of fluctuations. There areseveral reasons which might cause these fluctuations:

• 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, thisavailability test is a promising research area for future work. There couldbe many interesting research and application fields. For instance, the re-transmission mechanism in the APP layer should be added to guaranteethe availability. Also, when installers deploy the nodes, they can use someindicators in WSN like RSSI, link quality, routing table to determine thelong term availability in Thread network.

31

Chapter 6

Modeling and Validation ofLatency in the Thread MeshNetwork

6.1 System model of latency of multihop Thread meshnetwork

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

©&ABB&Group&August&6,&2016 |&Slide&5

Application&Layer

Transport& Layer(UDP)

Network&Layer(IPv6)

6LoWPAN

IEEE& 802.15.4(MAC)

IEEE& 802.15.4(PHY)

Application&Layer


Network&Layer(IPv6)

6LoWPAN& (Routing)

IEEE& 802.15.4(MAC)

IEEE& 802.15.4(PHY)

Application&Layer


Network&Layer(IPv6)

6LoWPAN(Routing)

IEEE& 802.15.4(MAC)

IEEE& 802.15.4(PHY)

Application&Layer


Network&Layer(IPv6)

6LoWPAN

IEEE& 802.15.4(MAC)

IEEE& 802.15.4(PHY)

Source:&Border&router DestinationActive&router Active&router

Sending&routeReceiving&route

T0:&propagation&time,&from&application&layer&to&physical&layerT1:&over&the&air&time&plus&routing&timeT2:&propagation&time,&from&physical&layer&to&application&layer

T0T2

T1

T0T2

! Routing&protocol&:&DVRPFIGURE 6.1: System model of the latency of Thread meshnetwork

RTT in single hop experimental test result

� Average RTT THR TX: 814 us

� Average RTT MAC TX: 5372 us

� Average RTT PHY TX: 4328 us

� Average RTT OTA: 16140 us

� Average RTT PHY RX: 265 us

� Average RTT MAC RX: 446 us

� Average RTT THR RX: 540 us

� Average RTT TOTAL: 27908 us

© ABB Group July 26, 2016 | Slide 6

� THR TX, PHY TX, PHY RX, MAC RX, THR RX time did not change too much.

� MAC TX change a lot because of the Back-off time in MAC layer.

� OTA includes the process time of the receivers and also changes due to the MAC TX of receiver side.

Application Layer

Transport Layer(UDP)

Network Layer(IPv6)

6LoWPAN

IEEE 802.15.4(MAC)

IEEE 802.15.4(PHY)

Application Layer

Transport Layer(UDP)

Network Layer(IPv6)

6LoWPAN

IEEE 802.15.4(MAC)

IEEE 802.15.4(PHY)

IPS TX

MAC TX

PHY TX

IPS RX

MAC RX

PHY RX

OTA

FIGURE 6.2: latency of different layer in Thread network

The system level model is based on the procedures of the packet mes-sage transmission in the Thread mesh network. Without loss of generality,in figure. 6.1, the 3-hop round trip procedures are reported, while figure.6.2 presents the delay of different layers in Thread protocol. The sourcenode is the border router while the destination is end device. The round

32 Chapter 6. Modeling and Validation of Latency in the Thread MeshNetwork

trip time can be separated into two parts: the sending route and the re-ceiving route. The sending route begins at the border router’s applicationlayer and then go through the network layer, MAC layer and physical layerwhere the transceiver transmits the message. Then the packet will be in therouting path which consists of the over-the-air (OTA) time and the relaynodes’ processing time. When the packet reaches the physical layer of thedestination, the destination node starts processing the packet and sendingthis packet from the physical layer to application layer. At this point, thesending route is finished while the receiving route begins. The destinationnode sends back the ACK command following the same route as sendingroute.

Based on the description above, round trip time of the packet can be di-vided into three categories according to the packet propagation process.The first one is the propagation time from application layer to physicallayer, 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 physi-cal layer to application layer T2. The whole RTT is defined as:

TRTT = 2⇥ T0 + T1 + 2⇥ T2 . (6.1)

Now we define in the details the component of the previous equation. ForT0 part, it consists of the processing time from application layer to MAClayer, denoted as IP stacks (IPS) TIPS0, the MAC layer processing timeTMAC0 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 inthe air is as fast as light. Therefore, the T1 depends on the relay nodes’routing time. When relay nodes are forwarding the message, the packetsare first entering physical layer, MAC layer and then 6LowPAN layer wherethe next forwarded nodes are decided. Then forwarded messages will gothrough MAC layer and physical layer to transmit to the next node. Onceit receives the MAC ACK back from the next relay node, the forwardingprocess of this node is finished. The forwarding processing time of onerelay 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 . Thetotal routing time is related to n. Considering the total routing time in multi-hop network:

T1 = 2⇥ (n� 1)⇥ TROUTE . (6.4)

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 theimplementation of Thread protocols except TMAC0. TMAC0 is the MAClayer service time that is not fixed because of exponential back-off processin the CSMA/CA mechanism. This random back-off time depends on thetraffic 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 thephysical layer TPHY2, MAC layer TMAC2 and the MAC to application layertime 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 ofMAC service time, are first presented by investigating the number of nodesin network and the effect of traffic conditions. Then in order to quantify thesystem level model, the hardware related latency is investigated. Finally, toverify the model, experimental studies are carried out, which show a goodconfirmation with the system level models. Details follow in the sequel.

0 10 20 30 40 50 60delay(ms)

0

0.01

0.02

0.03

0.04

0.05

0.06

0.07

0.08

0.09

0.1

probability

MAC service time distribution, 6 = 0.5

N=2N=5N=10N=20N=30N=40N=50

(A)

0 10 20 30 40 50 60delay(ms)

0

0.01

0.02

0.03

0.04

0.05

0.06

0.07

0.08

0.09

0.1

probability

MAC service time distribution, N = 10

6=0.16=0.36=0.56=0.76=0.9

(B)

FIGURE 6.3: MAC service time distribution. (a) shows therelationship between the probability distributions and thenodes numbers N with � = 0.2. (b) shows the relationshipbetween the the probability distributions and � with N =

10.

0 10 20 30 40 50 60 70data length (Bytes)

3400

3600

3800

4000

4200

4400

4600

4800

5000

5200

5400

phys

ical

laye

r del

ay (u

s)

y = 33.817*x + 3315.4

physical delaydata fit

(A)

0 10 20 30 40 50 60 70data length (Bytes)

780

790

800

810

820

830

840

850

IP s

tack

s la

yer d

elay

(us)

y = 0.9886*x + 778.7

IP stacks layer delaydata fit

(B)

FIGURE 6.4: experimental test of PHY layer latency (A) andIPS layer latency (B)


6.2.1 Statistical probability distribution of MAC service time

By calculating the analytical equations of the Markov chain model in the pa-per (Park et al., 2009b), the distribution of MAC service time TMAC0 is pre-sented with respect to the nodes numbers N and the network traffic condi-tions � . According to the parameters used in the Thread mesh network, thesettings are as follows: m0 = 5,m = 4, n = 3. A fixed packet length of L = 7is used in calculations. figure. 6.3 (a) shows the probability distribution ofMAC service time as function of different nodes N = 2, 5, 10, 20, 30, 40, 50with given � = 0.5. It can be easily observed that with the increase of nodesnumber N , the side lobes of the distribution function increase also and theprobability of low latency trapezoid area decrease. The reason is that theincrease of nodes number N will heavier the network traffics and thus in-crease the busy channel probability ↵ and collision probability Pc will alsoincrease. figure. 6.3 (b) presents the relationship between packet generationrate (1 � �) and the probability distributions with nodes number N = 10.The heavier the traffic situation in the network, the heavier tail it has. Thisis 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 experimen-tally investigated, which are closely related to the hardware aspects andimplementation of software stack. First, the hardware platform and soft-ware stack for experimental study are introduced. Second, the experimen-tal tests are presented to understand the latency introduced by hardwareand software implementation.

The hardware board FRDM-KW24D512 (kw24) together with the Thread1.0.0 preview software from NXP company (kw24) are used this paper’sexperimental 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 orderto calculate the total RTT . TMAC0 can be referred from MAC service timedistribution from last section if nodes number N and traffic condition � aregiven. 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 inter-val of each layers as shown in figure. 6.2. At first, the packet length of 10Bytes are applied in the test. The results are shown in the Table 6.1. Thenpacket length of 20 Bytes, 30 Bytes, 40 Bytes, 50 Bytes, 60 Bytes are tested inturns. The results show that delays of IPS TX and PHY TX are proportionalto packet length. Therefore, liner regression is used to estimate the latencyin IPS TX and PHY TX states, as shown in figure 6.4. Here the data lengthcounts only the payload of application layer, e.g., CoAP’s payload. Thelinear regression model fits very well with the testing data in both phys-ical layer and Thread network layer. For physical layer, the delay comesfrom the packet copying between micro-controller and radio transceivers


through serial peripheral interface (SPI), where

TPHY0 =

⇠L

vSb

⇡(6.6)

For Thread layer latency, it is decided by the copying speed inside themicro-controller in software stack implementation from application layerto 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 fixed,as shown in Table 6.1. The overall receiving latency is near 1ms, dependingon data processing in both micro-controller and radio transceivers.

TABLE 6.1: Experimental data of the Thread latency in dif-ferent 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 experimentalresults from Chapter. 5 are presented.

Taking into account that the latency of Thread mesh network can be cal-culated using the formula 6.1, in multihop case, the transmitting delay inMAC layer of all nodes can be obtained using convolutions, once the proba-bility distribution of MAC service time is known. The other kinds of delaysbesides MAC TX can be acquired from last section. The probability distri-bution of Thread mesh network and analytical model results are shown infigure. 6.5. As our system level model has not considered the applicationlayer retransmission, the CoAP layer retransmissions are ignored. The la-tency model fits well with the test results with respect to different hops. Itcan be noticed that the distribution of round-trip time is mainly decided byMAC back-off time.

6.2.4 Software tool to estimate the latency of Thread mesh net-work

In this section, a software tool to estimate the latency of Thread mesh net-work is implemented in MATLAB R2015B. As the figure. 6.6 shows, the pa-rameters N,�,m,mb,m0, L, Ls, Lc can be configured according to the setupof the Thread mesh network. The right side is the figure of estimation ofRTT according to the parameter configuration. It depicts the probabilitydistribution of RTT from 1 to 6 hops. First, this tool reveals the relation-ship among MAC parameters and the unicast latency in multihop mesh


network. Second, latency estimation gives the distribution of RTT with dif-ferent hops, which can serve as a guide for installers to deal with deploy-ment and configuration for Thread network.


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

0

0.02

0.04

0.06

0.08

0.1

0.12pr

obab

ility

ana: 1 hopana: 2 hopsana: 3 hopsana: 4 hopsana: 5 hopsana: 6 hopsanalytical model

experimental data

(A)

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

0

0.01

0.02

0.03

0.04

0.05

0.06

0.07

0.08

0.09

0.1

prob

abilit

y

ana: 1 hopana: 2 hopsana: 3 hopsana: 4 hopsana: 5 hopsana: 6 hops

experimental data

analytical model

(B)

FIGURE 6.5: Unicast latency results for 6-hop mesh networkof Thread: (A) case 1 (B) case 4


FIGURE 6.6: Software tool to estimate the latency of Threadmesh 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 BAhas been introduced. Although the landscape of standardization is stillfragmented, the BA industry has reached a consensus to adopt NIP con-nectivity technologies in the future. The 6LoWPAN adaption layer tearsdown the wall for WSNs and allows them enter the IP world by incorpo-rating the IPv6 packages in small link layer frames. Thread, which not justadopts 6LoWPAN, but also introduces many new features regarding secu-rity, reliability and low power consumption, aims at the target market ofhome and building automation.

Later in this thesis, a thorough experimental evaluation of Thread meshnetwork has been carried out with respect to signal coverage, unicast andmulticast latency, reliability , and availability. The signal coverage test re-sults provide a clear picture about the communication range of the IETFIoT stacks and Thread stacks. The results show the range performance isslightly 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 thatThread multihop messages running in the network have a low RTT andPDR. Within 6 hops in the mesh network, the RTT probability is near 99%in the 4 test cases covering the low traffic and heavy traffic conditions. Themulticast latency and reliability test also proves that Thread multicast mes-sages that are sent in large mesh networks have a satisfying performance asregards TCC and reliability. The reliability for multicast messages is morethan 98% in our test, while the TCC for 6 hops of Thread mesh network isgenerally within 200 ms with the probability 99%, giving a promising per-formance for further commercial products development. Finally, the avail-ability test shows that nearly 88% of nodes in the network are accessiblein the test with the employed methods. As the test did not consider ap-plication retransmission and is under stringent testing setting, this result isacceptable during research stage. However, in further commercial stages,the availability need be improved according to the application areas. Thisresult also shows a further research direction in the future.

A further step was took in this thesis to investigate the modeling of la-tency in Thread mesh network. a system level model regarding differentlayers for the latency of Thread mesh network is presented and validatedby the experimental results. The model presents a good match with experi-mental test results. Finally, a friendly tool using MATLAB is developed forinstallers 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 differ-ent network traffic conditions can be further investigated, given multicastis a crucial feature in the Thread protocol and is widely used in BA applica-tions. As most of our tests are carried out in local area network, web-basedor cloud-based testing about unicast and multicast latency, reliability andavailability are also promising research areas. For availability, adding theretransmission mechanism in the APP layer will also need to be test.

For the theoretical part, modeling of multicast latency of Thread meshnetwork will be further investigated in our future work. Furthermore, us-ing short term indicators in the network to predict long term availabilityperformance will be another work to consider. For example, when installersdeploy the nodes, they can use some indicators in WSN like RSSI, link qual-ity, 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 MetropolitanArea 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 depend-able and secure computing”. In: IEEE transactions on dependable and se-cure 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-hopduty-cycled 6LoWPAN networks”. In: Communication Systems, Networks& Digital Signal Processing (CSNDSP), 2014 9th International Symposiumon. 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 EfficientImplementation of RPL”. In:

Håkansson, Anne (2013). “Portal of research methods and methodologiesfor research projects and degree projects”. In: Proceedings of the Interna-tional Conference on Frontiers in Education: Computer Science and ComputerEngineering (FECS). The Steering Committee of The World Congressin 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 AllianceWhite Paper 3.

Hui, Jonathan and Richard Kelsey (2016). Multicast Protocol for Low-Powerand Lossy Networks (MPL). Tech. rep.

Hui, Jonathan and Pascal Thubert (2011). “Compression format for IPv6datagrams over IEEE 802.15. 4-based networks”. In:

Kruger, C. P. and G. P. Hancke (2014). “Implementing the Internet of Thingsvision 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. ofthe 1st USENIX/ACM Symp. on Networked Systems Design and Implemen-tation.

http://www.bacnet.org/

http://www.nxp.com

http://www.nxp.com

http://dx.doi.org/10.1109/INDIN.2014.6945586

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 overDECT 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 blue-tooth 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 forGreen Growth”. In: pp. 15–17.

Palattella, Maria Rita et al. (2013). “Standardized protocol stack for the in-ternet 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 Conferenceon. IEEE, pp. 163–167.

Park, P. et al. (2009a). “A generalized Markov chain model for effectiveanalysis 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 finiteretry limit and unsaturated traffic.

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 NetworkingConference, 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: mod-els, statistical methods, and applications. Vol. 396. John Wiley & Sons.

Ruta, Michele et al. (2014). “KNX, a worldwide standard protocol for homeand 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 re-sources (CoRE) working group, internet engineering task force (IETF), workin progress, draft-ietf-core-coap-13.

http://www.wifi.org/

http://dx.doi.org/10.1109/TVT.2012.2201221

http://cache.nxp.com/files/rf_if/doc/data_sheet/MKW2xDxxx.pdf?pspll=1

http://cache.nxp.com/files/rf_if/doc/data_sheet/MKW2xDxxx.pdf?pspll=1

http://dx.doi.org/10.1109/MOBHOC.2009.5337007

http://dx.doi.org/10.1109/MOBHOC.2009.5337007

http://dx.doi.org/10.1109/WCNC.2006.1683512

http://dx.doi.org/10.1109/WCNC.2006.1683512

http://dx.doi.org/10.1109/MIE.2011.942175

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 official 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:182ISSN 1653-5146

www.kth.se

Experimental Study of Thread Mesh Network for Wireless ...1040491/FULLTEXT02.pdf · Experimental...

Documents

Transcript of Experimental Study of Thread Mesh Network for Wireless ...1040491/FULLTEXT02.pdf · Experimental...