experimental study on low power wireless sensor network...

Experimental Study on Low PowerWireless Sensor Network Protocols with

Native IP Connectivity for BuildingAutomation

SHAOLING ZHU

Master’s Degree ProjectStockholm, Sweden July 2015

TRITA-EE 2015:73

Experimental Study on Low PowerWireless Sensor Network Protocols withNative IP Connectivity for Building

Automation

SHAOLING ZHU

Stockholm 2015

Automatic ControlSchool of Electrical EngineeringKungliga Tekniska Hgskolan

TRITA-EE 2015:73

i

Abstract

The recent development of wired and wireless communication technologiesmake building automation the next battlefield of the Internet of Things. Mul-tiple standards have been drafted to accommodate the complex environmentand minimize the resource consumption of wireless sensor networks. This Mas-ter Thesis presents a thorough experimental evaluation with the latest Contikinetwork stack and TI CC2650 platform of network performance indicators,including signal coverage, round trip time, packet delivery ratio and powerconsumption. The Master Thesis also provides a comparison of the networkprotocols for low power operations, the existing operating systems for wirelesssensor networks, and the chips that operate on various network protocols. Theresults show that CC2650 is a promising competitor for future development inthe market of building automation.

Keywords building automation; wireless sensor network; Internet of Things;6LoWPAN; RPL; CoAP

ii

Acknowledgments

First and foremost, I would like to express my sincere gratitude to my researchsupervisor, Zhibo Pang for offering this project opportunity, for his great pa-tience, motivation, enthusiasm and knowledge. His guidance helped me in allthe time of research and writing of this thesis. This paper would have neverbeen accomplished without his assistance and dedicated involvement. I wouldalso like to thank my supervisor and examiner, Carlo Fischione, for the con-tinuous support of my thesis. Even though I am doing my thesis outside theschool, he keeps reminding me of the schedule arrangements. Besides, I wouldlike to thank the group members in the automation department. They helpedme fulfill the two years of my pleasurable life at KTH. Last but not least, Iwould like to thank my parents, for supporting me substantially and spirituallythroughout my studying life.

iii

List of Acronyms6LoWPAN IPv6 over Low power Wireless Personal Area Networks

API Application Programming Interface

BAS Building Automation System

BLE Bluetooth Low Energy

CCA clear channel assessment

CDF cumulative distribution function

CoAP Constrained Application Protocol

CSMA/CA carrier sense multiple access with collision avoidance

DAO Destination Advertisement Object

DIO DODAG Information Object

DODAG Destination-Oriented Directed Acyclic Grph

EM Evaluation Module

ETX Expected Transmission Count

ICMP Internet Control Message Protocol

IETF Internet Engineering Task Force

IoT Internet of Things

IP Internet Protocol

IPv6 Internet Protocol version 6

LLNs Low-Power and Lossy Networks

MAC Media Access Control

MCU microcontroller

OS operating system

OSI Open Systems Interconnection

PDF probability density function

PDR packet delivery ratio

PHY Physical

iv

PLC Power Line Communication

RDC Radio Duty Cycling

REST representational state transfer

ROLL Routing over Low power and Lossy networks

RPL IPv6 Routing Protocol for Low-Power and Lossy Networks

RSSI received signal strength indicator

RTT round trip time

SoC System-on-Chip

TCP Transmission Control Protocol

TI Texas Instruments

UART Universal Asynchronous Receiver/Transmitter

UDP User Datagram Protocol

WPANs wireless personal area networks

WSN wireless sensor network

Contents

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Project Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Related Work 52.1 Network Protocols for WSN . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.2 Bluetooth Low Energy . . . . . . . . . . . . . . . . . . . . . . 62.1.3 6LoWPAN and RPL . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Embedded OS for WSN . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.1 TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2 Contiki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Chips for Low Power WSN . . . . . . . . . . . . . . . . . . . . . . . 102.3.1 Tmote Sky . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.2 TI CC2538 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.3 TI CC2650 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Test Plan 133.1 Signal Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Latency and Reliability . . . . . . . . . . . . . . . . . . . . . . . . . 143.3 Power Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Experimental Setup 174.1 Network Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1.1 802.15.4 PHY . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.1.2 Radio Duty Cycling . . . . . . . . . . . . . . . . . . . . . . . 184.1.3 CSMA/CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1.4 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1.5 ContikiRPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.1.6 UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

v

vi CONTENTS

4.1.7 Erbium CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2 Signal Coverage Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 214.3 Latency and Reliability Setup . . . . . . . . . . . . . . . . . . . . . . 224.4 Power Consumption Setup . . . . . . . . . . . . . . . . . . . . . . . . 25

5 Result Analysis 275.1 Signal Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.2 Latency and Reliability . . . . . . . . . . . . . . . . . . . . . . . . . 295.3 Power Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6 Conclusion and Future Work 39

Bibliography 41

Chapter 1

Introduction

The first chapter of this thesis provides a highly conclusive view of the whole project.In the first section, the idea of building automation and low power wireless sensornetwork (WSN) is discussed. Further, the specific problem this project aims tosolve and the goals to achieve are highlighted. The remaining sections provides themethods applied in the process and gives an outline of the rest document.

1.1 BackgroundBuildings are becoming more and more intelligent with the development of technol-ogy over the past few decades. The demands on building services are rising with theincreasing awareness of livability. As one of the most promising application domainsof the Internet of Things (IoT), building automation has become a new battlefieldof information and communications technologies.

Building automation is developed to satisfy the needs for health, safety and com-fort living conditions. The concept of building automation includes the integrationand centralized management of a building’s heating, ventilation, air conditioning,lighting, security and other systems through a Building Automation System (BAS).The BAS consists of interlinked networks of hardware and software, which moni-tors the environment around the building, and maintains the core functionality byschedule and automatically, from lighting, shading to temperature. Meanwhile, theBAS makes it possible to reduce the power consumption and maintenance costscompared to a non-controlled building. With centralized management, the BAS isable to gather information from distributed sensors, actuators, alarms and otherdevices, and send commands to thesis remote devices.

Although there are many advantages using the BAS, installation and upgrade ofthe system are much harder than expected. Early type of smart devices use wiredcommunication technologies, such as Power Line Communication (PLC). The wiresneed to be installed when the building is under construction. Most modern buildings

1

2 CHAPTER 1. INTRODUCTION

with the BAS follows such procedure. However, for the old buildings, renovationwork requires much effort. Even for the modern buildings, the increasing numberof smart devices dramatically increase the complexity of the wired system. Underthe difficulty of expanding the wired system scale, the researchers turn their focuson the WSN. [1][2][3][4]

A WSN is built of groups of specialized "nodes" that use radio for communication.Each node in the WSN is typically composed of several parts: a radio transceiver,a microcontroller (MCU), an electronic circuit and an energy source. The radiotransceiver is attached with an internal or external antenna to transmit data pack-ets. The electronic circuit connects the MCU to sensors for data collection, oractuators for specific action. The energy source can be mains powered, battery oreven embedded with energy harvesting. The scale of WSN varies from a few toseveral hundreds or even thousands of nodes.

A low power WSN has many advantages over a wired system network. First ofall, the WSN is easy and convenient to deploy. Nodes are often designed to belightweight and power efficient. With the battery life up to years, the child nodescan be installed anywhere as long as within the communication range of parentnodes. In a wired system, modify the location of devices after installation is hardlypossible. In comparison, the cost for moving a node in the WSN is much lower.Second, the installer does not need to fully understand the network topology inthe WSN, because the WSN uses certain routing metric to dynamically form thenetwork. As a result, the cost for constructing the network can be minimized.Furthermore, the property of large scalability of WSN enables the existence of largeredundant nodes. These nodes improve the robustness of the system and balancethe load of the network.

1.2 Problem Statement

There are many wireless technologies such as ZigBee, Bluetooth Low Energy (BLE)and IPv6 over Low power Wireless Personal Area Networks (6LoWPAN) developedfor WSNs. The major benefits of wireless solution is to improve user experiencesand reduce retrofit efforts. However it is challenging to use the wireless solutionas simple as the wired solution in terms of the complexity of wireless environment.Recently 6LoWPAN has attracted much attention for its ambition to connect everydevice using Internet Protocol version 6 (IPv6). In order to test the performanceof 6LoWPAN protocol which may become a potential rival to ZigBee and BLE, itis necessary to evaluate and measure the characteristics of 6LoWPAN network.

1.3. PROJECT GOAL 3

1.3 Project GoalThe goal of this project is to measure the round trip time (RTT), packet deliveryratio (PDR) and power consumption of 6LoWPAN network with specific hardwaredevices and software configurations. Our experiment result can be used to evaluateif the 6LoWPAN network fulfills the requirements of industrial applications.

1.4 MethodologyIn order to achieve the purpose of this thesis, several experiments are performedaccording to different requirements. The whole thesis work lasts 24 weeks involvingliterature review, planning, testing and final report. In the first stage we will inves-tigate and compare the 6LoWPAN protocol with ZigBee, BLE and other potentialcompetitors. Then the test platform will be modified for our test purpose. After thepreparation work, about half of the whole thesis time will be spent on performingthe tests. The analysis and report work will be in the last few weeks.

1.5 OrganizationThe rest of the document is organized as follows. Chapter 2 introduces some relatedwork within the scope of this thesis, including the developing network protocols andimprovements, the operating system (OS) involved in this subject, and the chips thatfulfill the requirements. Chapter 3 explains what the tests are and how these testsare carried out. Chapter 4 provides the instructions to build the test environment.The last two chapters (Chapter 5 and Chapter 6) presents the result of the wholeexperiment, the conclusion and future work.

Chapter 2

Related Work

This chapter highlights the previous work done by companies and researchers. Firsta summary of the three promising network protocols designed for low power WSN ispresented. Then two dominant embedded OS in the field of WSN are discussed andevaluated. The last section provides the chipsets suitable for the protocols above.

2.1 Network Protocols for WSN

2.1.1 ZigBee

The name ZigBee is originated from the wiggle dance of honey bees after their returnto the beehive. ZigBee is a set of specifications based on IEEE 802.15.4 standard[5]for low power wireless personal area networks (WPANs).[6] The standard is createdto address the need for a cost-effective, standards-based wireless networking solutionthat supports low data rates, low power consumption, security, and reliability.[7]ZigBee allows devices to sleep for most of the inactive period and is thus verypower efficient. ZigBee is most suitable for automatic and remote control system,and by far the most popular mesh networking standard on the market.

ZigBee devices operate in the industrial radio band 2.4 GHz in most jurisdictionsworldwide, with data transmitting rates up to 250 kbit/s. The network layer ofZigBee provides native support for star and tree network topology, and genericmesh networking. Every native WSN must have at least one coordinate device actsas central node to create and maintain the network. ZigBee allows nodes to berouters, good for extending the communication range.

The network Open Systems Interconnection (OSI) model of ZigBee is shown inFigure 2.1. The Physical (PHY) and Media Access Control (MAC) layer of ZigBeeare defined in IEEE 802.15.4 standard. The upper layers are either determined byZigBee compliant platform or by users. Early versions of ZigBee did not support IP-based routing protocol, which makes it difficult to integrate with existing network.

5

6 CHAPTER 2. RELATED WORK

The ZigBee alliance later published ZigBee IP specifications, trying to compete withother IP-based routing protocols.

Figure 2.1. ZigBee OSI model

2.1.2 Bluetooth Low Energy

The BLE technology is first proposed by Nokia as a light-weight subset of the classicBluetooth, and is supported from Bluetooth 4.0 specification. BLE is also a lowpower WPANs technology aimed at novel applications in the health-care, fitness,beacons, security and home entertainment industries.[8] BLE enables long-termoperation of Bluetooth devices that transmit at low data rate.

BLE devices operate in the industrial radio band 2.4 GHz, using 40 channels com-pared to 79 channels of classic Bluetooth. BLE has a data transmitting rate of 1Mbit/s. Unlike ZigBee, BLE only support scattered network topology. There mustbe at most one master device within its communication range, while multiple slavescan coexist. BLE The slave device is not able to route messages to further devices,unless it becomes a master to those devices. This feature prevents BLE devices toform a mesh network.

The network OSI model of BLE is shown in Figure 2.2. BLE uses its own definedMAC, network, transport and encryption layer, leaving the application layer for userspecification. BLE devices does not support IP-based routing, and the maximumlinkable device number is much less than ZigBee and other protocols.

2.1. NETWORK PROTOCOLS FOR WSN 7

Although there are plenty of wireless protocols for engineers and product designers,BLE still has great advantage and attraction. Both classic Bluetooth and BLE pro-tocols are originally supported by most mobile platforms (iOS, Android, WindowsPhone, etc.) and other wearable devices.

Figure 2.2. BLE OSI model

2.1.3 6LoWPAN and RPL

6LoWPAN

6LoWPAN is a standard for IPv6-based low power WPANs, observing the require-ments of IEEE 802.15.4 specifications.[9] It is also the name of a concluded workinggroup in the Internet area of Internet Engineering Task Force (IETF).[10]

Introducing IPv6 into WSN is considered inapplicable for a long time. Becausethe Internet Protocol (IP) stack needs large memory and high network bandwidth.It is difficult to connect low power WSN devices using IPv6. The appearance of6LoWPAN makes it possible to transplant IPv6 stack into small and battery con-strained devices.[11] The 6LoWPAN working group has defined header compressionand encapsulation mechanisms for IPv6 address.[12] These core features of 6LoW-PAN allow IPv6 packets to transmit over IEEE 802.15.4 based WSNs. 6LoWPANuses the compressed IPv6 Internet Control Message Protocol (ICMP) packet for-mat and optimized neighbor discovery policies[13]. In other words, 6LoWPAN is asimplified version of IPv6 targeted at resource constrained networks.


Different from ZigBee and BLE, 6LoWPAN only defines how IPv6 can be used in lowpower WSNs specified in IEEE 802.15.4 standard. The developer can freely chosethe radio for PHY layer and protocols for upper layers. With the help of 6LoWPAN,low power WSN can seamlessly working and communicating with existing networks.Large companies and groups are now trying to integrate the MAC layer of ZigBee,BLE and other protocols using 6LoWPAN. Thus different WSNs finally join a largerglobal network.

RPL

IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) is a routing proto-col for low power WSNs. In 2008, the IETF formed a new Working Group Routingover Low power and Lossy networks (ROLL) to standardize the IPv6-based routingsolution for Low-Power and Lossy Networks (LLNs). In 2010, routing requirementsfor building automation in LLNs were discussed in [14]. [15] officially detailed theRPL specifications, including the concepts, terms, packet formats and routing be-haviors.

RPL provides tree-like network topology. Every RPL Instance contains at least oneRPL Destination-Oriented Directed Acyclic Grph (DODAG). Each DODAG canbe regarded as one WPAN, with only one root node and several leaf nodes. RPLuses DODAG Information Object (DIO) and Destination Advertisement Object(DAO) messages to form and maintenance the network periodically. When onenode fails, RPL is able to quickly switch to another route, improving the stabilityof network. Packets can be routed both upward and downward directions, throughone or multiple hops.

RPL is very suitable for energy constrained devices working in the harsh environ-ment. The routing strategy of RPL prevents the occurrence of routing loops in thecase of node failure and packet loss. The evaluation of RPL routing performancehas shown promising results compared to ZigBee and BLE.[16]

2.2 Embedded OS for WSN

2.2.1 TinyOSTinyOS is developed and maintained by the University of California in Berkeley.[17]It is an open source, component-based embedded OS designed for WSNs. Now thecommunity of this project has thousands of developers, leading by the TinyOSAlliance.

TinyOS uses nesC language for programming, a dialect of the C language optimizedfor memory constrained devices.[18] As a component-based OS, TinyOS defines a setof components. Components are the key concepts of TinyOS, that all the commands,events and tasks are computational abstractions of components. Commands are

2.2. EMBEDDED OS FOR WSN 9

typically requests to a component to perform some actions, such as turn on theLED. Events are signals as completion of the requests. Tasks are usually posted tothe system scheduler for execution without interrupting the normal system work.

As one of the earliest supporters of 6LoWPAN, TinyOS provides full stack supportfor 6LoWPAN and RPL network,[19] as is shown in Figure 2.3. BLIP is the 6LoW-PAN implementation part in TinyOS, and TinyRPL is the actual implementationof RPL standard. Several experiments show that TinyOS provides efficient routingperformance in the low power and memory constrained WSNs.

Figure 2.3. TinyOS 6LoWPAN/RPL stack

2.2.2 ContikiContiki is an open sourced OS created by Adam Dunkels in 2002,[20] and maintainedby the Swedish Institute of Computer Science and thousands of developers aroundthe world. The Contiki community has become one of the largest and most activeIoT communities. Contiki is supported by Texas Instruments (TI), Atmel, Cisco,Sensinode, Zolertia, and many other companies and organizations.

Contiki is designed to satisfy the need for resource constrained hardware devices,including extremely low memory, power and bandwidth. The reported Contikimemory usage can be cut down to a few kilobytes. Contiki partially supports C pro-gramming language, thus there is little difficulty adapting to this platform. Contiki


provides a light weight programming model based on protothreads.[21] Protothreadsshares the features of multi-threading and event-driven programming, achieving alow memory overhead of each process. Contiki manages a real-time clock and anevent clock. System level operation and low layer of network operation is scheduledand triggered by the real-time clock. Event clock, on the other hand, services theupper layer processes and application defined processes that do not require highaccuracy.

Contiki provides three network mechanisms, the uIP TCP/IP stack, the Rime stackand the uIPv6 stack. At the time of release, Contiki uIPv6 stack developed byCisco was the smallest IPv6 stack to receive the IPv6 Ready certification. TheContiki uIPv6 stack implementation is shown in Figure 2.4. Like TinyOS, Contikinetwork stack also implements 6LoWPAN and RPL protocols in the OSI model.Furthermore, Contiki inserts an additional layer between PHY layer and MAC layer,called Radio Duty Cycling (RDC) layer. This layer enables the devices to shut downthe power of radio chips for most of the time.[22] With this mechanism the lifetimeof a battery powered device can be noticeably extended.

Figure 2.4. Contiki uIPv6 stack

2.3 Chips for Low Power WSN

2.3.1 Tmote SkyTmote Sky, also named Telos B, is an ultra-low power wireless sensor module usedin WSNs. The device integrates a TI MSP430 MCU and Chipcon CC2420 radiochip. Tmote Sky adopts many industrial standards such as IEEE 802.15.4 andUSB for communication with other devices through serial line or wireless. Further-more, Tmote Sky provides developing supports for thousand of mesh networkingapplications by integrating a series of sensors and peripherals, such as humidity andhumidity sensors. Tmote sky has passed rigorous tests and is supported by TinyOS,

2.3. CHIPS FOR LOW POWER WSN 11

Contiki and many other open-source IoT embedded OS. It is a smart module withthe features of robustness and lightweight. A picture of Tmote Sky is shown inFigure 2.5.

Figure 2.5. Tmote Sky

2.3.2 TI CC2538

The CC2538 is a power wireless MCU System-on-Chip (SoC) for high performanceIoT applications. The chip combines an ARM Cortex-M3 based MCU, providingup to 32KB on-chip RAM, and up to 512KB on-chip flash together with a IEEE802.15.4 radio. The tiny shaped chip is able to handle up to dated network stackswith high-level security and robustness applications. The 32 GPIOs and serial pe-ripherals enable the connection between the chip and the TI evaluation board, or thepower source. The SoC allows efficient authentication and encryption process, whileminimizing the workload for the MCU. Furthermore, three sets of low-power modeswith retention enable the quick sleep and recharge for periodic tasks, leveragingthe performance and power consumption. TI has provides a comprehensive driverlibrary and a series of debugging tools, which guarantees the smooth developmentof CC2538. The chip is also equipped with state of the art IoT technologies andsolutions such as ZigBee and 6LoWPAN. A picture of CC2538 Evaluation Module(EM) is shown in Figure 2.6.

2.3.3 TI CC2650

The CC2650 is a powerful wireless MCU for the next generation of IoT solutions.Besides ZigBee and 6LoWPAN, CC2650 adds additional support for BLE applica-tions. TI CC2650 belongs to the CC26xx family, targeting at cost-effective, ultra-low power and 2.4 GHz RF devices. Compared to CC2538, CC2650 provides abetter low-power management and longer battery lifetime, minimizing the currentconsumption of RF and MCU. The chip can easily work with coin cell batteries andin energy-harvesting applications with up to years of lifetime. Similar to CC2538,CC2650 also contains a 32-bit ARM Cortex-M3 based MCU and other ideal periph-


Figure 2.6. TI CC2538 evaluation board

erals. The SoC integrates an ultra-low power sensor controller for data collectioneven when the MCU is in sleep mode. The CC2650 targets at application domainswithin industrial, consumer electronics, medical and many others. The BLE con-troller and the IEEE 802.15.4 MAC are embedded into ROM and are partly runningon a separate ARM Cortex-M0 processor. This architecture improves overall systemperformance, decreases the power consumption and frees up flash memory for theapplication. A picture of CC2650 EM is shown in Figure 2.7

Figure 2.7. TI CC2650 evaluation board

Chapter 3

Test Plan

This chapter introduces the plans of necessary tests for this project, and explainsthe reasons for such tests. According to the project schedule, three tests should bedone one after another before the end of the project. The purpose of performingthese tests is to evaluate the network quality of low power WSN with the latesthardware and the cutting edge of network protocols. All the tests are performed inthe building owned by ABB Corporate Research Center.

3.1 Signal Coverage

The signal coverage test is the fundamental and preparation part of the wholeproject, since the communication range of nodes in low power WSN is largely af-fected by the transmit power and the surroundings. Although signal theory togetherwith math calculations can give an approximate model of signal coverage, it is notsufficient for the real case in a large building. The first target of our work is toestablish a multi-hop WSN that each node in the network is able to reach anotherone. So it is vital that we have a basic clue about the critical communication rangeof every two neighbor nodes, according to different transmit power settings.

Another purpose of the test is to examine the influence of using different WSN pro-tocols. Even though various WSN protocols operate on the 2.4 GHz frequency, theymay have slightly different communication range given the same transmit power.This test checks whether different WSN protocols have similar communication rangeor not, and from another aspect evaluates the performance of different protocols.

The signal coverage test is divided into four groups in total, listed as follows.

• BLE coverage test case 1

• BLE coverage test case 2

13

14 CHAPTER 3. TEST PLAN

• IEEE 802.15.4 coverage test

• 6LoWPAN coverage test

The first group involves a CC2650 EM and a Google Nexus 5 mobile phone. TheCC2650 EM acts as the BLE beacon, periodically broadcasting BLE packets. Themobile phone uses a BLE module to receive the incoming packets. The latter threegroups involve two CC2650 EM, one as a sender, and the other as a receiver. In thesecond group, the sender broadcasts the BLE beacon containing the informationof itself. The receiver runs the BLE stack provided by TI, calculating the signalstrength, the packet reception rate and other information. In the third group, thesender sends out standard IEEE 802.15.4 header packets without any additionalpayload. The receiver also runs a statistical program to maintain the packet infor-mation. In the last group, the sender uses the Contiki network protocols. It willsend out 6LoWPAN message to the receiver. As soon as the receiver gets the mes-sage, it will immediately reply with an acknowledgment message. The last group isthe only group in which the sender displays the packet reception information. Theformer three groups, however, uses the receiver to display such information.

3.2 Latency and ReliabilityThe latency and reliability statistics are the core indexes to evaluate the quality ofWSNs. And this test is also the most important part of the whole project. Severalrelated papers have studied the performance of 6LoWPAN and RPL networks invarious occasions. Very few literatures, however, are based on experimental eval-uations. For example, [23] discusses the memory usage, the power consumptionand the network quality of 6LoWPAN based on the hardware of TI CC2530 EM.[24] evaluates the network quality of Constrained Application Protocol (CoAP) us-ing RPL with the hardware of Tmote Sky. Other articles like [25] evaluates theperformance of 6LoWPAN in the Contiki Cooja simulator. However, because TIannounced the release of CC2650 EM just few months ago, there does not exist anyexperiment that evaluates the network quality based on this EM. Our experimentwill help determine if CC2650 EM fulfill the requirement of low power WSN in thefield of industry.

The latency and reliability test involves one CC2538 EM, one laptop and twentyCC2650 EM. The abstract network topology is shown in Figure 3.1. The CC2538EM is used as a sniffer, which captures the packets in the air and sends themto the laptop through Universal Asynchronous Receiver/Transmitter (UART) line.Then the laptop analyzes the incoming packets using softwares like Wireshark fornetwork diagnosis. The same laptop is connected to a RPL border router in orderto establish the 6LoWPAN network. All the information between the laptop andthe RPL border router is also exchanged through UART line. There is one RPLborder router, and nineteen nodes in the 6LoWPAN network in total, all of which

3.2. LATENCY AND RELIABILITY 15

are CC2650 EM. The nodes will be randomly spread throughout the building, butone node should be at least in the communication range of another. On the samechip of RPL border router, a CoAP client will be compiled an installed as well, forsending requests to the nodes in the 6LoWPAN network. All the nodes are runningthe CoAP server, providing the resources that the CoAP client can access.

Figure 3.1. Abstract network topology

As we know in the low power WSN, traffic load is a major influence to the latencyand reliability. In order to test the network quality under different traffic loads, weprepare four test scenarios as follows.

• 2 transaction/s from RPL border router, no extra load from CoAP servers

• 2 transaction/s from RPL border router, 0.2 transaction/s/server from CoAPservers

• burst from RPL border router, no extra load from CoAP servers

• burst from RPL border router, 0.2 transaction/s/server from CoAP servers

Note that in this test we only concern the transactions from RPL border router. Thenetwork quality within the 6LoWPAN network is outside the scope of this thesis.In the first scenario, every 0.5s the RPL border router sends a CoAP GET messageto a selected CoAP server and waits for the ACK message. There is no extra trafficin the network. In the second scenario, every 0.5s the router sends a CoAP GETmessage to a selected server and waits for the ACK message. Meanwhile everyserver in the network sends a CoAP GET message to a randomly chosen server and

16 CHAPTER 3. TEST PLAN

waits for the ACK message every five seconds. In the third scenario, the routercontinuously sends CoAP GET messages to a selected server and waits for ACKmessages. There is no extra traffic in the network. In the last scenario, the routercontinuously sends CoAP GET messages to a selected server and waits for ACKmessages. Meanwhile every node in the network sends a CoAP GET message to arandomly chosen server and waits for the ACK message every five seconds.

3.3 Power ConsumptionPower consumption is important for nodes in the WSN to achieve a long networklifetime. According to the TI technical documents, the CC2650 EM is developedwith excellent low power hardware, that enables the chip to enter some ultra-lowpower mode. However, only the support of hardware does not guarantee the chip tobe power-saving, a specially designed software algorithm is also needed. To achievea long lifetime, the radio transceiver must be switched off as much as possible. Butnaturally when the radio is switched off, the node is not able to send or receive anymessages. Thus the radio must be managed in a way that allows nodes to receivemessages but keep the radio turned off in between the reception and transmissionof messages. In Contiki, the radio duty cycling part is detached from the MAClayer and moves into its own layer, called the RDC layer. The aim of this test is tocompare the power consumption with or without this layer. In our assumption, thepower consumption with RDC layer should be much less than that without RDClayer, and the battery lifetime should be largely extended.

In order to perform the power consumption test, we consider using an oscilloscopefor observation and data generation. The oscilloscope is attached with a currentprobe that directly measures the current going through the CC2650 EM. We thenoutput the data to an laptop, and uses Matlab for calculation. In this test two casesare considered as follows.

• One transaction from CoAP client to CoAP server, without RDC layer

• One transaction from CoAP client to CoAP server, with RDC layer

In the first case, we turn off the RDC mechanism, forcing the chip to stay away allthe time. In the second case, we apply the RDC mechanism, that allows the nodeto sleep between transmission and reception occasions. More information about theRDC layer will be introduced in the next chapter.

Chapter 4

Experimental Setup

In this chapter, the experimental setup is presented. First of all, the network stackused in our test is split and discussed by layers. The latter three sections detailsthe setup for three tests, separately.

4.1 Network StackTable 4.1 shows the Contiki network stack used within the scope of this thesis. Thefollowing subsections explains how the implementation of these layers take effectand cooperate with neighbor layers.

Table 4.1. Contiki network stack

Layer ProtocolApplication Erbium CoAPTransport UDPNetwork IPv6/ContikiRPLAdaptation 6LoWPANMAC CSMA/CARadio Duty Cycling NullRDC/ContikiMACPhysical IEEE 802.15.4

4.1.1 802.15.4 PHY

The IEEE 802.15.4 working group has defined the PHY layer for low power WSN inthe IEEE standard 802.15.4. The 802.15.4 PHY layer is the initial layer in the OSImodel specially designed for low power devices, which provides the service of datatransmission and functions of upper layer management. The PHY layer operates onone of three potential frequency bands worldwide, ultimately certified by countries.The 2.4 GHz frequency band is the only band that is accepted worldwide. For

17

18 CHAPTER 4. EXPERIMENTAL SETUP

developing, the TI CC2650 EM runs on the 2.4 GHz frequency band and supportssixteen channels.

The PHY layer Application Programming Interface (API) is developed and main-tained by hardware manufacturers. These APIs are used to take control of the RFtransceiver for packet transmission. Contiki manages these APIs whenever a packetis generated and ready to transmit, or whenever the hardware state is about tochange.

4.1.2 Radio Duty Cycling

The RDC layer is a middle layer between the PHY layer and the MAC layer. Thename of RDC has explained the function of this layer, that take care of the sleepingperiod of nodes. The most commonly used RDC drivers supported by Contiki areX-MAC, CX-MAC, LPP, NullRDC and ContikiMAC. Among them ContikiMAC isthe latest RDC driver that provides a power efficiency solution for low power WSN.[22]

In our test we mainly focus on two RDC drivers, the NullRDC and ContikiMAC. Inthe signal coverage test, NullRDC is chosen as the effective communication range isnot determined by this layer. In the latency and reliability test the performance ofusing NullRDC driver will be tested. In the power consumption test both NullRDCand ContikiMAC drivers are applied.

The NullRDC and ContikiMAC driver have totally different management of sleepperiod. NullRDC defines an empty RDC layer that will never be used. In otherword, the radio will never be switched off at any time. NullRDC does not pro-vide any power saving mechanisms, thus has the best performance for latency andreliability, but has the largest power consumption.

ContikiMAC is the default mechanism that is compatible with most hardware de-vices supported by Contiki. Figure 4.1 shows the basic transmit principle of Con-tikiMAC. The ContikiMAC driver will turn off the radio between packet intervalsfor most of the time. According to [22] and the Contiki source code, ContikiMACchecks the channel for incoming packets with a default frequency of 8 Hz. If thechannel is clear, the node will shortly return to sleep, and the radio is powered off.Otherwise, if the received signal strength indicator (RSSI) exceeds some threshold,the node shall keep awake until another full packet is received, or until the waitingtime expires. When transmitting a packet, ContikiMAC ensures the reception ofthe receiver by continuously transmitting same the packet for the time period largerthan the receiver’s sleeping time. ContikiMAC allows the use for phase optimiza-tion, which guarantees some sort of time synchronization. With phase optimization,the transmitter will send the packet to the receiver just before it is expected to wake.

4.1. NETWORK STACK 19

Figure 4.1. A ContikiMAC unicast transmission

4.1.3 CSMA/CA

Contiki provides two MAC layer drivers, carrier sense multiple access with collisionavoidance (CSMA/CA) and NullRDC. NullRDC does not do any retransmissionor collision detection actions and is thus not suitable for the WSN. Without thecollision detection, packets may be corrupted or lost. For the tests we only considerthe CSMA/CA mechanism, the only MAC layer that retransmits packets in case ofcollision.

Contiki implements the CSMA/CA mechanism to avoid packet collision. Oncethe RDC channel check detects a collision in the network, the packet transmissionprocess will be delayed for some time. The CSMA/CA mechanism decides the timeinterval of retransmitting the packet as well as retransmission time.

4.1.4 6LoWPAN

Contiki implements the RFC4944 document for transmission of IPv6 packets overIEEE 802.15.4 networks.[12] The implementation defines the addressing, fragmen-tation and header compression of IPv6 packets. Since IPv6 packets are resourceconsuming, the fragmentation and header compression are necessary and proved tohave better network performance in the low power WSN. The Contiki 6LoWPANbelongs to the adaptation layer. As a middle process of packets, it is called bythe MAC process when a 6LoWPAN packet is received, and by the User DatagramProtocol (UDP) or ContikiRPL process when a packet needs to be sent.

The Contiki 6LoWPAN implementation mainly provides two functions, fragmenta-tion and IPv6 header compression. The IEEE standard 802.15.4 has defined thepacket size to be 127 octets, which is far too low than the IPv6 packets. Thereforeit is necessary to shrink the size of IPv6 packets to fit into the LLNs. As is known toall, the IPv6 address has the length of 128 bits without compression. Furthermore,many protocols requires both the source and destination address in one packet.


Thus the nodes cannot exchange information efficiently. 6LoWPAN provides IPv6header compression that compresses the unnecessary bits of IPv6 address. Thecompression and decompression procedure is stored in the ROM, thus allows moreinformation in the packet.

The fragmentation takes effect when the packet size exceeds 127 octets. Upperlayer applications may send oversize packets, then the 6LoWPAN layer fragmentsthe packet into several smaller packets to meet the requirement. The fragmentedpacket contains the necessary information for packet reassembly. For example, thefirst fragment carries a header that includes the datagram size and a datagramtag. The subsequent fragments carry a header that includes the datagram size, thedatagram tag and the offset. The receiver then uses the information to reassemblethe packets and sends to upper layer applications.

4.1.5 ContikiRPL

ContikiRPL is the Contiki implementation of RPL protocol to meet the require-ments of LLNs and has been accepted by IPSO Alliance as a standard implemen-tation. ContikiRPL belongs to the network layer in the OSI model, and provides alow-cost but efficient routing strategy based on ranks.

The ContikiRPL implementation separates message format, message process, sched-uled tasks and objective functions into different files, allowing for the replacementand modifications by the developers. ContikiRPL implements two objective func-tions, one is based on hops from the root called OF0,[26] the other is based onExpected Transmission Count (ETX) called MRHOF.[27]

A typical RPL network is constructed with the following steps. First there must beat least one RPL root node in the network. The root node generates and broadcastsDIO messages to announce the existence of itself. When the nearby nodes hear fromthe root node, if they do not belong to any other RPL network, they will add theaddress of the root node into their parent address table and generate an upwardlink, and send DAO messages to the root node. The root node then adds the addressinto its child address table and generates a downward link to the neighbor and thusa route is established. The root node will keep broadcasting DIO messages witha increasing interval. Meanwhile the neighbors begin broadcasting DIO messagescontaining the information of the RPL network they belong to, the address of them-selves and routing information to the nodes that have longer distance to the rootnode. The procedure iterates until all the potential nodes join the RPL network,then the DIO and DAO messages are exchanged mainly for maintenance.

In the ContikiRPL implementation, a child node can have at most one active parentnode. The selection of parent node is controlled by the objective function. Everyobjective function has a method for rank calculation. The calculation is based onthe rank of parent node and link metric. The objective function decides how the

4.2. SIGNAL COVERAGE SETUP 21

link metric is carried out. For example, the link quality between the child node toone parent node is better than another, then the link metric of this link is lower,informing that the child spends less effort to transmit packets through this link.The parent rank is added to the link metric to generate a new rank for the childnode. The child node will choose the smaller rank as its own new rank, and set thatparent as the preferred parent.

4.1.6 UDP

UDP is implemented on top of RPL, and belongs to the transport layer in the OSImodel. Although Contiki implements both Transmission Control Protocol (TCP)and UDP protocols, CoAP only uses UDP for packet transmission. In addition,CoAP has a built-in retransmit mechanism to avoid packet loss, thus using UDP ismore simple and lightweight. In this thesis we choose UDP protocol as the networklayer implementation.

4.1.7 Erbium CoAP

Erbium CoAP is a low power CoAP implementation together with representationalstate transfer (REST) engine designed for Contiki, which later become the officialCoAP implementation for the Contiki OS. Erbium CoAP follows the guidelines ofRFC 7252 with features of blockwise transfers and observing.[28]

The IETF CoAP is an application layer protocol specified for resource constrainedapplication such as LLNs. CoAP adopts many features and patterns from HTTPsuch as URIs and resource abstraction. The use of URIs makes CoAP easy tocommunication with the World Wide Web. However, as is stated earlier, CoAP onlyuses UDP for packet transmission. TCP is proved to have poor network quality inthe server or resource constrained network environment, where in most cases energyconsumption weighs more than packet loss or message delay.

CoAP provides reliable message transmission by making a message as Confirmable(CON). A Confirmable message must be replied with an Acknowledgment mes-sage (ACK). If the waiting time expires and the Acknowledgment message is stillmissing, the sender will retransmit the Confirmable message within the maximumretransmission times. CoAP also supports other two message types, which are Non-confirmable message (NON) and Reset message (RST).

4.2 Signal Coverage Setup

Figure 4.2 shows how the signal coverage test is performed. First, the chips areloaded with the program that containing the protocol we want to test. Then weplace the sender on the desk of our office for convenience, and the receiver in the


corridor. The red icon surrounded by green rings in Figure 4.2 represents the senderin the office, and the mobile icon represents the receiver in the corridor.

Figure 4.2. Signal coverage test setup

When the test program starts, the sender continuously sends packets to the receiverwith a fixed transmit power. Meanwhile we begin walking towards the end of thecorridor, away from the sender. We gather information about RSSI and PDR alongthe corridor to decide the distance that the signal can reach. Then we alter thetransmit power and begin another test.

4.3 Latency and Reliability SetupThe purpose of latency and reliability test is to evaluate the long-range and multi-hop performance of CC2650 chips configured with 6LoWPAN stack. Figure 4.3shows the equipment for placement. The CC2650 EM is connected to a SmartRF06Evaluation Board, which provides power supply from the battery. The device isthen put inside an engineering plastic box for safety issues in the company. Finallythe box is connected to a tripod for deployment.

The deployment of nodes in the two buildings is shown in Figure 4.4. There is abridge between building 194 and building 206 in the third floor, and the distance oftwo buildings is within the effective communication range of nodes. The red circlein the third floor denotes the RPL border router, the root of 6LoWPAN network,located in our office. Other nodes are placed elsewhere in the building, but mainlyin the meeting rooms, lounges and corridors. Figure 4.5 provides a vertical view ofnode placement in the building. It should be pointed out that the lines betweennodes do not represent the real network topology, because RPL network uses notonly range but also other parameters to generate the routes, and the routes arechangeable according to the network quality.

Table 4.2 shows the experimental parameters used in the test. We detect the signalinterference in the building on the default channel 25 and thus switch to channel26. The transmit power is set to the default value of CC2650, which is 5dBm for

4.3. LATENCY AND RELIABILITY SETUP 23

Figure 4.3. Node placement

the longest communication range. The RDC layer is switched off in the first placefor the convenience of first stage evaluation. There are 20 nodes in total includinga RPL border router. The border router only sends CoAP GET messages to othernodes. In the test that considers random traffic, the CoAP client on the 19 nodeswill also send CoAP get messages to a randomly selected node. All the CoAP GETmessages are responded with CoAP ACK messages.

When the test program start, the RPL border router starts sending CoAP GETmessages to nodes in the network from the nearest to the furthest. The borderrouter has a built-in function to calculate the time interval between sending andreceiving the packet, and prints it to the computer window through serial line. Inthis way data is collected. When there is need for extra traffic in the network, thecommand is sent by using CoAP PUT message. The CoAP server in the networkopens a CoAP client program as soon as receiving the PUT message. The programdoes the same thing as the border router does, except that the client program onthe node does not produce any output information. The border router sends 300packets to each node in a single test. There are 19 CoAP server nodes in the networkand 4 test groups. Thus we acquire 22800 valid numbers of RTT data.


Figure 4.4. Horizontal view of node placement in the building

Figure 4.5. Vertical view of node placement in the building

4.4. POWER CONSUMPTION SETUP 25

Table 4.2. Experimental setup parameters

Parameter ValueContiki Version 3.x

Platform TI SmartRF06EB+CC2650EM

RDC NullRDCChannel 26Transmit Power 5dBmTotal number of nodes 20Border Router CoAPGET message packet size 53Bytes

CoAP Client CoAPGET message packet size 70Bytes

CoAP Server CoAPACK message packet size 63Bytes

4.4 Power Consumption SetupFigure 4.6 shows the oscilloscope we used to evaluate the power consumption bymeasuring the current through the chip directly. In order to eliminate the currentthrough peripherals, all the unnecessary jumpers on the SmartRF06 EvaluationBoard are removed, shown in Figure 4.7, and the functions for LEDs, sensors andstatistics are commented out. An electric wire is used to connect the "VDD TOEM" pins instead of the jumper. Because the standby current of CC2650 is ratherlow, the current is amplified by 30 times to raise the accuracy.

When testing, the oscilloscope shows the real-time current measurement of the chip.By carefully turning the knobs, we manage to capture the whole process of packettransmission and reception. The device is configured as a CoAP client, runninga simple application unicasting a CoAP GET message to the CoAP server. Whenconfigured with NullRDC, the device will never turn off its RF chip, thus the standbycurrent is assumed to be much higher than that configured with ContikiMAC. Inthe next chapter, the test results are presented and compared with our assumptions.


Figure 4.6. The oscilloscope for power consumption test

Figure 4.7. The node for power consumption test

Chapter 5

Result Analysis

5.1 Signal Coverage

This section presents the results of signal coverage test. Figure 5.1-5.5 provide avisual map of communication range for different groups. The colored dots of variousshapes on the map means the furthest location that a packet can be received with achosen protocol at a given transmit power. It can be seen from the figures that theresults of different protocols are more or less the same. Especially for the first twotest groups, the BLE communication range is less dependent on the type of receiver.When considering the distance on same floor, the IEEE 802.15.4 and CoAP packetscan be heard from the furthest location. The transmit power has a major influenceon the signal coverage. As can be seen from figures, the signal coverage is longestwith 3dBm transmit power, and shortest with -3dBm transmit power. Moreover,the horizontal distance is related to the floor where the receiver is placed. Whenthere are more floors between the sender and the receiver, the horizontal distance ofsignal coverage becomes shorter. An extreme example shows that when the receiveris placed on the basement floor, the receiver can never receive packets with transmitpower less than 3dBm.

Figure 5.1. Signal coverage result on floor C

27

28 CHAPTER 5. RESULT ANALYSIS

Figure 5.2. Signal coverage result on floor D

Figure 5.3. Signal coverage result on floor B

Figure 5.4. Signal coverage result on floor A


Figure 5.5. Signal coverage result on floor K

Table 5.1 summarizes the result of coverage test. It can be clearly seen from thestatistics that using the same transmit power the IEEE 802.15.4 packets has thebest performance for signal coverage, closely followed by CoAP packets. The twogroups of BLE packets are almost the same but has much shorter reception range.In later tests we mainly transmit CoAP messages thus the result of border router-> 6LoWPAN node group can be regarded as the reference.

Table 5.1. Signal coverage result displayed in meters

Transmit Power(dBm) Floor BLE->

PhoneBLE->BLE

802.15.4->802.15.4

Border Router->6LoWPAN node

3C 39.5 40.7 66.3 60.5B 27.6 30.5 34.0 28.7K 6.8 11.5 12.3 10.3

-3C 34.2 33.5 37.3 35.2B 19.5 21.0 24.5 23.5K No No No No

-9C 21.8 21.1 28.3 28.3B 11.4 12.4 16.3 14.1K No No No No

5.2 Latency and Reliability

This section provides the result in terms of RTT and PDR. The latency and relia-bility test is carried out in a very complex building environment involving differentsizes of offices, meeting rooms and corridors. The node placement is given in Figure4.4 and 4.5. Because the RPL network is established and maintained automati-cally by the RPL root node, the routes may alter during the test due to noise orenvironment changes. The result is sorted by number of hops. We use cumulative


distribution function (CDF) curves to represent the RTT based on hop counts.

Figure 5.6-5.11 shows the CDF curves that are generated by Matlab. There arethree vertical lines in the figures, indicating deadlines that we set as a parameter toevaluate the network quality in industrial applications. The vertical line from leftto right denote 150ms, 250ms and 1000ms, separately.

It can be seen from Figure 5.6 that for single hop the probability of RTT equalto 150ms or less varies from 0.88 to 0.91 depending on the scenarios discussed inSection 3.2. And most packets in this interval are arrived within 10ms. The networkquality is highest when there is no traffic in the network and the burst mode is off.On the contrary, when there is random traffic in the network and the burst modein on, the average RTT suffers a severe decrease. Figure 5.6 also shows for one hopnodes, a packet has a probability of at least 0.97 to arrive within 1000ms, and canreach as high as 0.99 when the traffic is low. For hops more than 1, the probabilityof RTT within a given deadline has a slight decrease. In general, RTT increaseswith the increase of hop counts. In this test we observe at most 6 hops in thenetwork.

Figure 5.6. Latency result for one-hop nodes

Figure 5.12-5.14 shows the probability density function (PDF) curves with respectto number of hops for each test group. Because CoAP has a built-in retransmission


Figure 5.7. Latency result for two-hop nodes

Figure 5.8. Latency result for three-hop nodes


Figure 5.9. Latency result for four-hop nodes

Figure 5.10. Latency result for five-hop nodes


Figure 5.11. Latency result for six-hop nodes

mechanism to deal with packet loss. All the packets are successfully received in thistest. However, when the retransmission happens a lot of time will be wasted towait for the retransmit. In this case the packet can be identified as lost. Thus wecalculate the PDR in terms of deadlines.

Figure 5.12 shows the PDR curves when the deadline is set to 150ms. It can beclearly seen from the figure that one hop nodes have the highest PDR. We also noticethat the PDR is higher when there is no extra traffic in the network. When the hopincreases the PDR drops due to more retransmissions. An exception happens thatwhen there is random traffic in the network, the PDR of 5 hop nodes is even lowerthan that of 6 hop nodes. After investigation we find that the placement of the 5hop node is in the center of two subnets. Thus the node consumes a high networkload routing information between the subnets.

Figure 5.13 and 5.14 extend the deadline for RTT, result in a higher PDR. Thedifferent requirements of deadline serve applications in different scenarios in buildingautomation. Compared to the PDR at 150ms, the PDR at 250ms and 100ms reachesalmost 0.95 for one hop nodes. Even for 6 hop nodes, 95 percent of the packetsarrives within 1000ms for all cases.


Figure 5.12. Packet delivery ratio within 150ms


5.3. POWER CONSUMPTION 35


5.3 Power Consumption

This section provides the result of power consumption test. Figure 5.15 showsthe current curve during a single transaction using NullRDC mechanism, whileFigure 5.16 presents the current curve during a single transaction using ContikiMACmechanism.

It can be seen from Figure 5.15 that the transaction period can be roughly dividedinto three parts, transmission, reception and idle listening. The first peak of trans-mission part indicates that the MCU wakes to do some preprocessing work and theRF chip performs a clear channel assessment (CCA). After CCA the chip decidesto transmit the CoAP GET message. The transmitting time is determined by thepacket length and radio frequency. In the figure the rectangular wave denotes thetransmitting current, closely followed by another smaller wave, which indicates thepost process part. The link layer acknowledgment is also transmitted in this timeslot by the receiver. Then the MCU returns to sleep, and the RF chip keeps awakefor incoming packets. For the idle listening part only the RF chip consumes power.When the CoAP ACK message arrives, a peak appears indicating the reception ofthe packet. Since this is the application layer acknowledgment, the sender will alsoresponse with a link layer acknowledgment. Then the MCU goes back to sleep andwaits for the next round.


Figure 5.15. Power consumption without RDC

Figure 5.16 shows the current measurement of a complete transaction period usingContikiMAC. By comparing with NullRDC, the average current of idle listeningperiod of ContikiMAC is much lower. This is because the ContikiMAC mechanismshuts off the RF chip for most of the time. The transmitting period is dividedinto four parts. In the first part the MCU wakes to do the preprocessing work.Then the RF chip wakes to perform CCA for six groups, each group two times,by default. Thus it can be from the figure that there are twelve peaks before therectangular waves. In the third part, the RF chip starts transmitting the packet.As we know ContikiMAC does not know whether the receiver is listening, so it willkeep transmitting the same packet continuously with a short interval until it reachesthe maximum transmit time or receives the link layer acknowledgment. The fourthpart includes receiving the acknowledgment and do the post process work. Thenboth MCU and RF chips return to sleep. In the idle listening part, the RF chipwakes occasionally to check if there is packets in the channel. This behavior resultsin small peaks with fixed interval on the current curve. The default channel checkrate is 8Hz which is equal to 125ms. When there is traffic in the channel, the RFchip keeps awake to receive the next packet, because it may miss the header of theformer packet. In the figure we can see a very high peak in the reception period,

5.3. POWER CONSUMPTION 37

indicating the reception of a full packet. Then the sender will also sends back a linklayer acknowledgment. At last both MCU and RF chip return to sleep and wait forthe next round.

Figure 5.16. Power consumption with RDC

Table 5.2 shows the calculation of average current during each period. The resultdoes not contain the time interval of these periods, because the total transmittingtime of ContikiMAC depends largely on the network environment and the RDC ofthe receiver. However, the table still clearly shows that for all three periods theaverage current of ContikiMAC is lower than that of NullRDC. Especially for theidle listening part, ContikiMAC has lowered the current less than one milliampere.The mechanism is very power efficient for low rate WSN where the nodes do notsend packets for most of the time.


Table 5.2. Power consumption statistics

RDC Type State Average Current(mA)

NullTX 8.765Idle 6.198RX 8.514

ContikiTX 7.754Idle 0.311RX 6.463

Chapter 6

Conclusion and Future Work

In this thesis project, a thorough evaluation of newly marketed TI CC2650 platformwith a full Contiki-based network stack is presented. The background of buildingautomation, IoT and WSN are introduced. Then the related work done by otherresearchers are evaluated and compared with ours. Though there are a lot of eval-uations and experiments on wired or wireless protocols, no performance evaluationhas been done on the CC2650 platform on a large scale network with full Contiki-based network stack, to our knowledge. In the related work the thesis also providesa comparison between existing network protocols, OS and chips that fulfill the re-quirement of IP-based low power WSN. The comparison suggests that the CC2650platform and Contiki OS together with Contiki network stack should be the mostpromising implementation for our experiment. Then the plans for three tests arecarried out to evaluate the performance of our implementation from many aspects.The experiment setup provides a detailed explanation of Contiki network stack andguidelines for the tests. At last the experiment result is presented and evaluated.

It can be concluded from the coverage test results, that the communication rangewill be slightly affected by the protocol we use, but not obvious especially at alow transmit power. The type of receiver does not affect the reception range aswell. Moreover, different protocols serve different applications and environments,there is no one protocol that exceeds other protocols in every aspect. The latencyand reliability test results show that the network has a low RTT and high PDRwhen the traffic is low and the route is short. As the number of hops increases,the reliability of a success transaction drops due to retransmission at each hop, andaverage RTT increases since the route is longer. When the traffic in the networkrises, the reliability also decreases because the hidden node problem causes morechannel collisions, or the channel is too busy to transmit the packet within a givenperiod. The power consumption test compares two different RDC mechanisms.The results show that ContikiMAC is very power efficient and suitable for lowrate WSNs. According to our experiment results, the TI CC2650 platform withContiki OS is competitive for the ideal industrial WSN solution for IP-based building

39

40 CHAPTER 6. CONCLUSION AND FUTURE WORK

automation applications.

The future work includes the improvement of network stack and precision of experi-ment results. For the network stack, although Contiki has been developed for yearsand is quite mature, during the test we still observe several times of network failure.The precision of experiment results happens when measuring the power consump-tion. The current probe for our measurement is reported not precise enough tomeasure current on the scale of microampere. In later test the researcher shouldreplace it with a more accurate current probe.

Bibliography

[1] Pangun Park, Carlo Fischione, and Karl Henrik Johansson. Adaptive IEEE802.15. 4 protocol for energy efficient, reliable and timely communications.In Proceedings of the 9th ACM/IEEE international conference on informationprocessing in sensor networks, pages 327–338. ACM, 2010.

[2] Pangun Park, Carlo Fischione, Alvise Bonivento, Karl Henrik Johansson, andAlberto Sangiovanni-Vincent. Breath: an adaptive protocol for industrial con-trol applications using wireless sensor networks. Mobile Computing, IEEETransactions on, 10(6):821–838, 2011.

[3] Alvise Bonivento, Carlo Fischione, and Alberto Sangiovanni-Vincentelli. Ran-domized protocol stack for ubiquitous networks in indoor environment. InIEEE CCNC, volume 1, pages 152–156. Citeseer, 2006.

[4] Alvise Bonivento, Carlo Fischione, Luca Necchi, Fernando Pianegiani, and Al-berto Sangiovanni-Vincentelli. System level design for clustered wireless sensornetworks. Industrial Informatics, IEEE Transactions on, 3(3):202–214, 2007.

[5] IEEE standard for local and metropolitan area networks–part 15.4: low-ratewireless personal area networks (LR-WPANs). IEEE Std 802.15.4-2011 (Revi-sion of IEEE Std 802.15.4-2006), pages 1–314, Sept 2011.

[6] Wikipedia. ZigBee — Wikipedia, the free encyclopedia, 2015. [Online; accessed29-June-2015].

[7] TI. ZigBee wireless networking overview. Technical report, Texas Instruments,2013.

[8] Wikipedia. Bluetooth low energy — Wikipedia, the free encyclopedia, 2015.[Online; accessed 30-June-2015].

[9] JeongGil Ko, Andreas Terzis, Stephen Dawson-Haggerty, David E Culler,Jonathan W Hui, and Philip Levis. Connecting low-power and lossy networksto the internet. Communications Magazine, IEEE, 49(4):96–101, 2011.

[10] Wikipedia. 6LoWPAN — Wikipedia, the free encyclopedia, 2015. [Online;accessed 30-June-2015].

41

42 BIBLIOGRAPHY

[11] Nandakishore Kushalnagar, Gabriel Montenegro, C Schumacher, et al. IPv6over low-power wireless personal area networks (6LoWPANs): overview, as-sumptions, problem statement, and goals. RFC4919, August, 10, 2007.

[12] Gabriel Montenegro, Nandakishore Kushalnagar, J Hui, and D Culler. Trans-mission of IPv6 packets over IEEE 802.15. 4 networks. Internet proposed stan-dard RFC, 4944, 2007.

[13] Zach Shelby, Samita Chakrabarti, E Nordmark, and C Bormann. Neighbordiscovery optimization for IPv6 over low-power wireless personal area networks(6LoWPANs). Technical report, 2012.

[14] Jerry Martocci, Pieter Mil, Nicolas Riou, and Wouter Vermeylen. Buildingautomation routing requirements in low-power and lossy networks. 2010.

[15] Tim Winter. RPL: IPv6 routing protocol for low-power and lossy networks.2012.

[16] Olfa Gaddour and Anis Koubâa. RPL in a nutshell: a survey. ComputerNetworks, 56(14):3163–3178, 2012.

[17] Jason Hill, Robert Szewczyk, Alec Woo, Seth Hollar, David Culler, andKristofer Pister. System architecture directions for networked sensors. In ACMSIGOPS operating systems review, volume 34, pages 93–104. ACM, 2000.

[18] David Gay, Philip Levis, Robert Von Behren, Matt Welsh, Eric Brewer, andDavid Culler. The nesC language: A holistic approach to networked embeddedsystems. In Acm Sigplan Notices, volume 38, pages 1–11. ACM, 2003.

[19] JeongGil Ko, Stephen Dawson-Haggerty, Omprakash Gnawali, David Culler,and Andreas Terzis. Evaluating the performance of RPL and 6LoWPAN inTinyOS. In Workshop on Extending the Internet to Low Power and LossyNetworks (IP+ SN), 2011.

[20] Adam Dunkels. Contiki: Bringing ip to sensor networks. ERCIM News, (76),2009.

[21] Adam Dunkels, Oliver Schmidt, Thiemo Voigt, and Muneeb Ali. Protothreads:simplifying event-driven programming of memory-constrained embedded sys-tems. In Proceedings of the 4th international conference on Embedded networkedsensor systems, pages 29–42. Acm, 2006.

[22] Adam Dunkels. The contikimac radio duty cycling protocol. 2011.

[23] Jimmy Assarsson and Linus Karlsson. Performance of constrained wire-less devices in the internet of things. University Essay from Lunds Univer-sitet/Datavetenskap, pages 1650–2884, 2013.

BIBLIOGRAPHY 43

[24] Thomas Potsch, Koojana Kuladinithi, Matthias Becker, Peter Trenkamp, andCarmelita Goerg. Performance evaluation of CoAP using RPL and LPL inTinyOS. In New Technologies, Mobility and Security (NTMS), 2012 5th Inter-national Conference on, pages 1–5. IEEE, 2012.

[25] Matthias Kovatsch, Simon Duquennoy, and Adam Dunkels. A low-power CoAPfor Contiki. In Mobile Adhoc and Sensor Systems (MASS), 2011 IEEE 8thInternational Conference on, pages 855–860. IEEE, 2011.

[26] Pascal Thubert. Objective function zero for the routing protocol for low-powerand lossy networks (RPL). 2012.

[27] Omprakash Gnawali. The minimum rank with hysteresis objective function.2012.

[28] Zach Shelby. Constrained RESTful environments (CoRE) link format. 2012.

experimental study on low power wireless sensor network...

Documents