energy-efficient communication with lightweight m2m in iot ...1306358/fulltext01.pdf · oma:s...

IN DEGREE PROJECT ELECTRICAL ENGINEERING,SECOND CYCLE, 30 CREDITS

, STOCKHOLM SWEDEN 2018

Energy-Efficient Communication with Lightweight M2M in IoT Networks

CARLOS GONZALO PECES

KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE

Master’s Thesis Report

Title: Energy-Efficient Communication with LightweightM2M in IoT Networks

Author: Carlos Gonzalo Peces

Supervisors: Nicolas Tsiftes, Ph.D.Joakim Eriksson, Ph.Lic.

Examiner: Prof. Ingo Sander

Affiliation 1: School of Electrical Engineering and Computer Science,KTH Royal Institute of Technology

Affiliation 2: ETS de Ingenieros de Telecomunicación,Universidad Politécnica de Madrid

Stockholm, 12th of March, 2018

This work is supported by RISE SICS ABand developed in cooperation with theNetworked Embedded Systems Group.

Acknowledgements

It is incredible how time flies. It feels like yesterday when I started my studies at theuniversity, and now I am finished and ready to continue with my career. Now it is timeto thank to all the people that helped me in this way, since the very beginning.

First of all I would like to show my gratitude to the Networked Embedded Systemsgroup. Special mention to Nicolas and Joakim, my supervisors, for guiding me in thewhole Master’s thesis and teaching me through all the project. Also thanks to Thiemofor giving me the opportunity to do the thesis in this group and for his kindness sincethe first time I contacted him. Thanks to all the others for the friendly environment,it was really nice to work in a place like this.

What to say about all the friends I made in Stockholm... this experience wouldnot have been the same without you. Thanks Jorge, Patryk, Jonas and Alex for beingthe best corridor mates ever. Also Sebastian, Guayen, Irene, Enrique, Pablo, Vicent,Viktor, Mathilde, Alfonso... for all the dinners, trips and parties.

Thanks to all the people from my home university, la ETSIT. To Ana, Alberto,Jorge, Marta, Cris, Jose, Isa... Thank you for all those good times despite the stressfrom the studies. Thanks to all the people from "el labo", the B105 Electronic SystemLab, for being my home for two years and introducing me in this field, and especiallyto Alvaro, for all the things you have taught me, not only the academic ones.

Also I do not want to forget about all the people not so linked to the university,but that also were with me all this time. Thanks to all the people from Coslada forbeing there since the very beginning, special mention to Mario, Diego, and of course tothe whole Cachas Team, my basketball team. Also thank you people from Berrocalejofor all the laughs and funny moments that we have lived together.

Special mention to my family. Thank you mum and dad for your unconditionalsupport, for being always beside me, and for always believe in me. Thanks to mygrandmas, uncles, aunts, cousins... you are also a part of what I am nowadays.

And finally, thank you Dessy for being with me through all this seven years. Youhave always believed in me, since the very beginning when I was unsecure about beingable to become an engineer, until now that I have finally completed it. I have no wordsto express how grateful I am.

Thanks to all, from my heart...

Carlos Gonzalo Peces

v

Abstract

OMA’s Lightweight Machine to Machine (LwM2M) is an application protocol fordevice management in the Internet of Things (IoT) that has been recently publishedand widely adopted in a lot of projects. The protocol is designed to operate in sensornetworks and machine-to-machine environments, where one of the main constraintsis the energy consumption since the nodes are usually battery powered. Differentstrategies to achieve high energy efficiency in IoT networks have been developed, butthere is no deep knowledge about the performance of LwM2M operating with them.Moreover, the specification of this protocol includes one strategy, called the QueueMode, which could be more efficient than the usual ones because it has been specifiedfor this particular protocol.

This project aims to implement this Queue Mode at both sides of thecommunication, and then evaluate its performance by comparing it with TSCH, whichis the standard MAC protocol used in IEEE 802.15.4 that defines a way of radio dutycycling. It has been proven to achieve a high energy efficiency, and that is the mainreason why it is selected. The comparison is performed according to several metricsto have a comprehensive evaluation, and in different kind of scenarios, with differentnumbers of IoT devices and different parameters in the communication.

The implementation was done inside the Contiki-NG OS for the client side, whichis an operating systems designed for constrained devices. For the server side it hasbeen carried out inside the Eclipse Leshan code, which is a LwM2M implementationin Java made by the Eclipse Foundation. As a result of the evaluation, it shown thatboth implementations operate correctly.

This thesis contributes as a guideline for making decisions about which low powerstrategy is better to use depending on the IoT scenario and the type of application. Itshows that for many use cases Queue Mode is a better option than TSCH because itachieves a higher energy efficiency and the rest of the metrics used in the evaluationhave also improved values. TSCH has a better performance only in demandingscenarios or in cases where the communication is not produced at fixed time instants.

The thesis was developed in cooperation with RISE SICS AB, NetworkedEmbedded Systems Group.

Keywords: IoT; LwM2M; low power consumption; TSCH; Contiki-NG; EclipseLeshan.

vii

Sammanfattning

OMA:s Lightweight Machine to Machine (LwM2M) är ett applikationsprotokollför enhetshantering i Sakernas Internet (IoT) som nyligen har publicerats ochbörjat användas i många projekt. Protokollet är utformat för att fungera isensornätverk och maskin-till-maskin miljöer, där en av de viktigaste begränsningarnaär energiförbrukningen eftersom noderna vanligtvis är batteridrivna. Olika strategierför att uppnå hög energieffektivitet i sensornätverk har utvecklats, men det finns ingendjup kunskap om hur LwM2M fungerar med dem. Dessutom innehåller specifikationenav LwM2M en strategi kallad Queue Mode (köläge) som kan vara effektivare än devanliga strategierna eftersom den har utvecklats direkt för det här protokollet.

Detta examensarbete syftar till att implementera detta köläge på båda sidorav kommunikationen och sedan utvärdera prestandan genom att jämföra det medTSCH, vilket är ett MAC-protokoll specificerat i IEEE 802.15.4-standarden. Tidigarearbeten har visat att TSCH kan uppnå en låg energiförbrukning, vilket är den främstaanledningen till att detta protokoll väljs ut för att jämföra mot LwM2M:s köläge.Jämförelsen inkluderar flera olika typer av mätvärden och scenarier för att få enomfattande utvärdering, samt med flera olika antal sensor noder och parametrar.

Implementationen gjordes för Contiki-NG OS på klientsidan, vilket är ett operativ-system för resursbegränsade IoT-enheter. På serversidan har implementationen gjortsför Eclipse Leshan, vilken är en LwM2M-implementation skriven i Java och publice-rad av Eclipse Foundation. Som en följd av utvärderingen har det visat sig att bådaimplementationerna fungerar korrekt.

Detta examensarbete bidrar med riktlinjer för att fatta beslut om vilkenenergibesparingsstrategi som är bättre att använda beroende på IoT-scenariot ochtypen av applikation. Utvärderingen visar hur Queue Mode i många användningsfallär ett bättre alternativ än TSCH eftersom det uppnår en högre energieffektivitet utanatt de andra typerna av mätvärden påverkas av det. I vissa fall uppnås dessutomförbättrade resultat även i de andra typerna av mätvärden. TSCH har endast bättreprestanda i krävande scenarier eller i fall där kommunikationen inte genereras vidbestämda tillfällen.

Examensarbetet har genomförts hos Networked Embedded Systems-gruppen påRISE SICS AB.

NYCKELORD: IoT; LwM2M; låg energiförbrukning; TSCH;Contiki-NG;Eclipse Leshan.

ix

Resumen

OMA’s Lightweight Machine to Machine (LwM2M) es un protocolo de aplicación parala gestión de dispositivos en el ámbito del Internet de las Cosas (IoT). Ha sido publicadorecientemente y está siendo utilizado en gran cantidad de proyectos. El protocoloestá diseñado para operar en redes de sensores y comunicaciones machine-to-machine,donde una de las mayores restricciones es el consumo de energía ya que los dispositivossuelen estar alimentados con baterías. Existen diferentes estrategias para conseguiralta eficiencia energética en redes IoT, pero no hay un conocimiento profundo sobre elfuncionamiento de LwM2M cuando hace uso de ellas. Además este protocolo incluyeen su especificación una nueva estrategia, llamada Queue Mode, la cual podría ser máseficiente que las utilizadas habitualmente.

Este proyecto tiene como objetivo implementar el Queue Mode en ambas partesde la comunicación, y posteriormente evaluar su funcionamiento comparándolo conTSCH, que es el protocolo MAC estándar utilizado por IEEE 802.15.4, el cual defineuna manera de reducir el ciclo de trabajo de la radio. Ha sido probado que esteprotocolo consigue una alta eficiencia energética, y por eso es el seleccionado para laevaluación. La comparativa se realiza con respecto a distintas métricas para ampliarel alcance de la evaluación, y en diferentes tipos de escenarios, utilizando distintosparámetros en la comunicación y redes con mayor o menor número de dispositivos.

La implementación ha sido realizada en el sistema operativo Contiki-NG para ellado cliente, el cual ha sido diseñado para operar en dispositivos IoT. Para el ladoservidor se ha utilizado el código de Eclipse Leshan, el cual es una implementación deLwM2M en java realizada por la Eclipse Foundation. Como resultado de la evaluación,se muestra que el funcionamiento de estas implementaciones es correcto.

Los resultados de este trabajo contribuyen a modo de guía para decidir quéestrategia de bajo consumo es mejor utilizar dependiendo del escenario y del tipode aplicación. La comparativa demuestra que para para muchos usos Queue Modesupone una mejor opción que TSCH porque consigue una mayor eficiencia energéticay además el resto de métricas utilizadas no solo no son afectadas, sino que tambiénmejoran. TSCH es una mejor opción únicamente para casos en los que el servidorrequiere datos con una alta frecuencia o en instantes de tiempo no prefijados.

Este trabajo fue desarrollado en colaboración con RISE SICS AB, NetworkedEmbedded Systems Group.

Palabras clave: IoT; LwM2M; bajo consumo; TSCH; Contiki-NG; Eclipse Leshan.

xi

Contents

Acknowledgements v

Abstract vii

Sammanfattning ix

Resumen xi

Acronyms List xxiii

1 Introduction 1

1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Thesis Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Background 5

2.1 Contiki-NG Operating System . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Protothreads, Processes and Events . . . . . . . . . . . . . . . . 7

2.1.2 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Network Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Constrained Application Protocol (CoAP) . . . . . . . . . . . . . . . . 10

2.3.1 Messaging Model . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.2 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.3 URI scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.4 CoAP Methods and Response Codes . . . . . . . . . . . . . . . 12

xiii

xiv Contents

2.4 Lightweight Machine to Machine (LwM2M) . . . . . . . . . . . . . . . 13

2.4.1 Resource Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4.2 Bootstrap Interface . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.4.3 Client Registration Interface . . . . . . . . . . . . . . . . . . . . 16

2.4.4 Device Management and Service Enablement Interface . . . . . 18

2.4.5 Information Reporting Interface . . . . . . . . . . . . . . . . . . 19

2.4.6 Queue Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.5 Low Power MACs in Contiki . . . . . . . . . . . . . . . . . . . . . . . . 22

2.6 Measuring Energy Consumption in Contiki . . . . . . . . . . . . . . . . 25

3 Queue Mode Implementation at the Client Side 27

3.1 Implementation in the LwM2M RD client . . . . . . . . . . . . . . . . 28

3.1.1 Finite State Machine operation without Queue Mode . . . . . . 28

3.1.2 Finite State Machine operation with Queue Mode . . . . . . . . 29

3.1.3 Design and implementation of the client awake time . . . . . . . 31

3.2 Implementation in the LwM2M engine . . . . . . . . . . . . . . . . . . 32

3.2.1 Design and implementation of the Information Interface withQueue Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.3 The Queue Mode Object . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4 Queue Mode Implementation at the Server Side 37

4.1 Complete implementation of the Queue Mode . . . . . . . . . . . . . . 38

4.1.1 Listener for registration and update messages . . . . . . . . . . 39

4.1.2 LwM2mQueue class for managing the Queue Mode of each client 39

4.1.3 Request Sender with Queue Mode operation . . . . . . . . . . . 40

4.1.4 Complete Queue Mode Operation in the LwM2M Core . . . . . 42

4.2 Reduced implementation with Presence Listeners . . . . . . . . . . . . 43

5 Evaluation 45

5.1 Hardware platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.2 Evaluation Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Contents xv

5.3 Evaluation Metrics and Scenarios . . . . . . . . . . . . . . . . . . . . . 47

5.4 Measurement of the Defined Metrics . . . . . . . . . . . . . . . . . . . 50

5.5 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.5.1 Queue Mode Scenarios . . . . . . . . . . . . . . . . . . . . . . . 51

5.5.1.1 Synchronized requests scenario . . . . . . . . . . . . . 51

5.5.1.2 Randomized requests scenario . . . . . . . . . . . . . . 57

5.5.2 TSCH Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.5.2.1 Synchronized requests scenario . . . . . . . . . . . . . 58

5.5.2.2 Randomized requests scenario . . . . . . . . . . . . . . 62

5.6 Comparison between Queue Mode and TSCH . . . . . . . . . . . . . . 62

5.6.1 Energy Consumption . . . . . . . . . . . . . . . . . . . . . . . . 63

5.6.1.1 Sending period 10 s . . . . . . . . . . . . . . . . . . . . 63

5.6.1.2 Sending period 60 s . . . . . . . . . . . . . . . . . . . . 64

5.6.1.3 Sending period 5min . . . . . . . . . . . . . . . . . . . 64

5.6.2 Round Trip Time . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.6.3 Packet Reception Rate . . . . . . . . . . . . . . . . . . . . . . . 66

5.6.4 Memory footprint . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.7 Battery lifetime calculations . . . . . . . . . . . . . . . . . . . . . . . . 68

5.8 Alternative scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.8.1 Monitoring scenario . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.8.2 Scenario with default values recommended by OMA specification 72

6 Conclusions and Future Work 74

References 76

List of Figures

1.1 Typical IoT scenario with a sensor network connected to the cloudthrough a border router. . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2.1 Processes execution in the Contiki-NG OS. . . . . . . . . . . . . . . . . 8

2.2 Network stack used for the communication in the developed IoT networks. 9

2.3 Resource model scheme in LwM2M. . . . . . . . . . . . . . . . . . . . . 14

2.4 Communication scheme in the Bootstrap interface of LwM2M. . . . . . 15

2.5 Communication scheme in the Client Registration interface of LwM2M. 17

2.6 Communication scheme in the Device Management and ServiceEnablement interface of LwM2M. . . . . . . . . . . . . . . . . . . . . . 18

2.7 Communication scheme in the Information Reporting interface ofLwM2M. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.8 Communication scheme using LwM2M protocol with Queue Modeenabled. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.9 TSCH slotframe example for the communication between two nodes. . . 23

3.1 Finite state machine implementing the RD client. . . . . . . . . . . . . 29

3.2 Finite state machine implementing the RD client with Queue Modeoperation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3 Problem (a) and solution (b) in the information interface when usingQueue Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1 Architecture of the Leshan server code. Only the interesting objects forthe Queue Mode implementation are shown. . . . . . . . . . . . . . . . 39

4.2 Flowchart of the Queue Mode request sender. . . . . . . . . . . . . . . 41

4.3 Complete operation of the Queue Mode inside the Leshan server. Onlythe objects added to the Leshan core for this purpose are shown. . . . . 42

xvii

xviii List of Figures

4.4 Queue Mode operation inside the Leshan server for the pull request.Only the necessary objects added to the Leshan core are shown. . . . . 44

5.1 The Zolertia Firefly hardware platform. . . . . . . . . . . . . . . . . . . 46

5.2 Setups used to build the IoT networks for the experiments in theevaluation part. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.3 Current consumed over time by the client node in a Queue Modescenario with sleeping time 60 s and awake time 5 s. . . . . . . . . . . . 52

5.4 Accumulated energy consumed over time by the client node in a QueueMode scenario with sleeping time 60 s and awake time 5 s. . . . . . . . . 53

5.5 Accumulated energy consumed over time by the client node in a QueueMode scenario with sleeping time 60 s and awake time 5 s and 2 hops. . 55

5.6 Mean round trip time in a Queue Mode scenario for different numberof hops. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.7 Number of retransmissions performed for each packet in a Queue Modescenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.8 Accumulated energy consumed over time by the client node in a QueueMode randomized scenario with sleeping time 60 s and awake time 5 s. . 57

5.9 Mean Round Trip Time in a Queue Mode randomized scenario withsleeping times of 10 s and 60 s. . . . . . . . . . . . . . . . . . . . . . . . 58

5.10 Current consumed over time by the client node in a TSCH scenario withminimal schedule and a sending period of 60 s. . . . . . . . . . . . . . . 59

5.11 Total energy consumed by the client node in a TSCH scenario with theminimal schedule and a sending period of 60 s. . . . . . . . . . . . . . . 60

5.12 Mean Round Trip Time in TSCH scenarios with different schedules andfor different numbers of hops. . . . . . . . . . . . . . . . . . . . . . . . 61

5.13 Number of retransmissions performed for each packet in a TSCHscenario with Orchestra-71. . . . . . . . . . . . . . . . . . . . . . . . . 62

5.14 Energy comparison for sending period 10 s between Queue Mode withdynamic adaptation and TSCH. . . . . . . . . . . . . . . . . . . . . . . 63

5.15 Energy comparison for sending period 60 s between Queue Mode with1 s client awake time and TSCH. . . . . . . . . . . . . . . . . . . . . . 64

5.16 Energy comparison for sending period 5min between Queue Mode withdynamic adaptation and TSCH. . . . . . . . . . . . . . . . . . . . . . . 65

5.17 Round trip time comparison between all Queue Mode and TSCHscenarios, with different numbers of hops. . . . . . . . . . . . . . . . . . 66

List of Figures xix

5.18 Packet Reception Rate comparison between all Queue Mode and TSCHscenarios, with different number of hops. . . . . . . . . . . . . . . . . . 67

5.19 Battery lifetime comparison between all Queue Mode and TSCHscenarios, for different sending periods. . . . . . . . . . . . . . . . . . . 70

5.20 Accumulated energy consumed over time by the client node in amonitoring scenario using Queue Mode with dynamic adaptation andsleeping time 60 s. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.21 Accumulated energy consumed over time by the client node in amonitoring scenario using TSCH with Orchestra-17 and notificationperiod 60 s. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.22 Accumulated energy consumed by the client node in a Queue Modescenario with default recommended client awake time (93 s) and asleeping time of 5min. . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

List of Tables

3.1 Resources present in the Queue Mode object. . . . . . . . . . . . . . . 35

4.1 Necessary features to support the Queue Mode at the server side. . . . 38

5.1 Metrics defined for the evaluation of the Queue Mode in comparisonwith TSCH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.2 Current consumption values of the Zolertia Firefly hardware platform. . 50

5.3 Transmission and reception duty cycles (in %) in the Queue Modescenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.4 Transmission and reception duty cycles (in %) in the TSCH scenarios. . 60

5.5 Memory footprint of the different LwM2M software modules with QueueMode enabled and disabled. . . . . . . . . . . . . . . . . . . . . . . . . 68

5.6 Total system’s memory footprint when using Queue Mode or TSCH. . . 68

xxi

Acronyms List

API . . . . . . . Application Programming Interface

CoAP . . . . . . Constrained Application Protocol

CRC . . . . . . Cyclic Reduncancy Check

CSMA . . . . . Carrier Sense Multiple Access

DTLS . . . . . . Datagram Transport Layer Security

FSM . . . . . . Finite State Machine

HTTP . . . . . Hypertext Transfer Protocol

IFFT . . . . . . Integer Fast Fourier Transform

IoT . . . . . . . Internet of Things

IP . . . . . . . . Internet Protocol

ISM . . . . . . . Industrial, Scientific and Medical

JSON . . . . . . JavaScript Object Notation

LPM . . . . . . Low Power Mode

LwM2M . . . . Lightweight Machine to Machine

M2M . . . . . . Machine-to-Machine

MAC . . . . . . Medium Access Control

OMA . . . . . . Open Mobile Alliance

OS . . . . . . . . Operating System

PRR . . . . . . Packet Reception Rate

RD . . . . . . . Resource Directory

xxiii

xxiv Acronyms List

REST . . . . . . Representational State Transfer

RPL . . . . . . . IPv6 Routing Protocol for Low-Power and Lossy Networks

RTOS . . . . . . Real Time Operating System

RTT . . . . . . . Round Trip Time

SICS . . . . . . Swedish Institute of Computer Science

SoC . . . . . . . System-on-Chip

TCP . . . . . . Transmission Control Protocol

TLV . . . . . . . Type-Length-Value

TSCH . . . . . . Time-Slotted Channel Hopping

UDP . . . . . . User Datagram Protocol

URI . . . . . . . Uniform Resource Identifier

WSN . . . . . . Wireless Sensor Network

Chapter 1

Introduction

The IoT is one of the most important engineering topics nowadays among academyand industry. It was created for military applications [1], but it has being appliedin many different scenarios in the last years. Some examples are smart cities, smartagriculture, and smart homes. This tendency is predicted to continue increasing inthe near future, and some studies show that by 2022 there will be around eighteenbillion IoT devices [2]. Two main parts are typically involved in these IoT scenarios,as Figure 1.1 shows: the sensor networks and the cloud. The sensor networks often usewireless communications, forming what is called Wireless Sensor Networks (WSNs) —a research topic that contributed to a large class of IoT systems. WSNs are networkscomposed of different small devices, called sensor nodes, that are in charge of sensingthe environment and can also act over it. These sensor nodes usually contain amicroprocessor, a battery, a radio transceiver and antenna, and several sensors andactuators. The nodes collaborate and communicate with each other to send theircollected data over the Internet to the cloud. This is the other part of the classical IoTscenarios, which is formed by several servers that receive the data from the sensors andprocess it for the purpose of the application, and also control and manage the nodesby sending messages to them. The connection between the two parts are usually theborder routers, which are special nodes that act as sinks receiving all the messages fromother sensor nodes in the network and forward them through an Internet connectionto the servers present in the cloud.

Figure 1.1: Typical IoT scenario with a sensor network connected to the cloud through aborder router.

1

2 CHAPTER 1. INTRODUCTION

One of the main challenges in sensor networks is to have low power consumptionin the nodes in order to achieve high battery lifetimes, sometimes reaching severalyears. The hardware part that usually consumes the most is the radio. In orderto minimize its consumption, the main strategies that have been developed over theyears are usually located in the low layers of the network stack, which are the MediumAccess Control (MAC) and the physical layer. These layers use radio duty cycling,which means that the radio is turned off most of the time, and is turned on only incertain instants, determined by a short period, in order to enable the communication.The time when the radio is turned off is on the order of hundreds of milliseconds,and the time when the radio is turned on is on the order of a few milliseconds, thusresulting in a low radio duty cycle that achieves a high energy efficiency.

Nonetheless, this strategy is usually not enough to achieve the desired lifetime, andalso it is made independently in these two network stack layers, without taking intoaccount the protocols that run on top of them. Moreover, the strategy is also appliedinternally in the sensor network without taking into account the communication withthe servers present in the cloud, which is in the end what defines the purpose of theIoT scenario.

Nowadays, full standard protocols have been developed and started to be usedfor communication in IoT scenarios. One of these is Open Mobile Alliance (OMA)Lightweight Machine to Machine (LwM2M), an application layer protocol which is incharge of managing the sensor nodes using a normal Representational State Transfer(REST) [3, Chapter 5] interface. This interface makes it compatible with other existingand widely used Internet standards, like Hypertext Transfer Protocol (HTTP) [4]. TheLwM2M protocol contains a low power mode, called Queue Mode, in which the sensornodes can sleep for long periods of time where the server cannot communicate withthem, and they wake up at some points to enable this communication. In the end,the application layer is the one that defines the communication that is made in thescenario, and therefore this strategy could be more efficient than the radio duty cyclingused by the MAC and physical layers. For many applications it is not necessary thatthe radio is turned on so often as is done by these MAC methods, simply becausethere is no communication to do in many of those time instants. Examples of theseapplications are the monitoring scenarios where the nodes are sensing the environment,like a room or a mechanic structure, and sending the collected data to the server. Ifthis data is not critical, it can be sent within long periods of time, or only when therehas been a significant change in the values. Therefore, the periods where the radio isoff can be much longer in these cases, achieving lower radio duty cycles and thereforehigher energy efficiency.

1.1 Problem Statement

In general, there is little knowledge about how strategies for low power consumptionaffect LwM2M, as it is a protocol that has been published recently. Moreover, thereis even less knowledge about the Queue Mode operation. Its specification is brief andopen to interpretation, and for the moment there are not many implementations orevaluations of it.

1.2. Contributions 3

Therefore, the main goal of this Master’s thesis project is to evaluate theperformance of LwM2M when using low power strategies at different levels of thenetwork stack. For this purpose, a comparison between the mentioned MAC andphysical layer strategies with the Queue Mode is done, for which is necessary alsoto implement this mode. The MAC protocol that is used for the comparison isTime-Slotted Channel Hopping (TSCH), because it has been shown that it achievesa good energy efficiency and it is also the standard protocol in IEEE 802.15.4 [5].This evaluation is performed in the testbed present at RISE SICS 1, inside an officeenvironment. Hence, the project has two different parts:

• The implementation of the protocol at both communication sides: the client sideinside the Contiki-NG Operating System (OS) [6] that runs in the IoT nodes, andthe server side inside the Eclipse Leshan software [7]. This phase includes thecorresponding testing to ensure the correct operation of the protocol, accordingto the specification.

• Evaluation of the LwM2M operation using low power strategies, by comparingthe Queue Mode with TSCH. Several metrics are examined, such as batterylifetime, round trip times and packet losses, and also different scenarios withdiverse parameters are used in the experiments in order to cover as many IoTapplications as possible.

1.2 Contributions

This project has one main scientific contribution, which is to gain an understandingof how LwM2M’s performance is affected by different methods for reducing the energyconsumption related to communication in different layers of the network stack. Theselected methods are the MAC protocol TSCH and the Queue Mode included directlyinside LwM2M. As a result of the performed evaluation, it is shown in which kind ofsituations and applications each protocol is a better option to adopt, and therefore thethesis can be used as a guideline for making decisions about the low power strategies infuture projects. To the best of our knowledge, this is the first performance evaluationfor LwM2M of this kind, and may guide future work on low-power wireless networkingstacks.

In order to achieve this goal, the implementation of the Queue Mode has been doneat both sides of the communication. This implementation is done in two differentsoftware stacks, which are Contiki-NG and Eclipse Leshan. The code developed forthe server side has been accepted as a pull request and integrated in the master branchof the Eclipse Leshan GitHub repository [8], which shows the success of the performedimplementation and makes a contribution to the IoT community. The code developedfor the client side is also planned to be integrated in Contiki-NG. Therefore, all theimplemented software in this Master’s project is open source and can be used in futureLwM2M projects.

1RISE SICS: https://www.sics.se/

https://www.sics.se/

4 CHAPTER 1. INTRODUCTION

1.3 Thesis Structure

The remaining part of the thesis is structured as follows. Chapter 2 contains all thebackground necessary to understand this project, including the OS that is used, andall the communication protocols involved at different layers of the network stack. Italso explains how to measure power consumption in order to make the evaluation.Chapters 3 and 4 include the implementation of the Queue Mode in the client andserver side respectively, explaining all the details and the design decisions that havebeen made. Chapter 5 contains the evaluation and results obtained, pointing outthe main differences between the operation of both protocols according to the definedmetrics. Finally Chapter 6 includes the conclusions drawn from the evaluation part,and makes suggestions for the future work.

Chapter 2

Background

This section explains the important background concepts that are involved in thisthesis, for a good understanding of the report. First it introduces Contiki-NG, theOS that runs in the IoT devices, with all the features that make it suitable forthe purpose of this project. This section also describes some of the details of itsinternal implementation. Then, the main protocols that are used and modified areexplained in detail, which are the two application protocols Constrained ApplicationProtocol (CoAP) and LwM2M, and also TSCH which is the MAC protocol used in thecomparison. Finally, the software module used to measure the energy consumption isalso described.

2.1 Contiki-NG Operating System

Contiki-NG (Next Generation) [6] is an OS designed for resource-constrained devicesin the IoT, which is based on the Contiki OS [9]. Contiki was developed to runin microprocessors with constraints in terms of processing capabilities, memory, andpower supply among others. The main purpose of this OS is to connect tiny devices tothe Internet and therefore it has been widely used in the development of IoT networks.For this, it has several communication protocols implemented and ready to use atdifferent levels of the network stack, such as the application protocol CoAP [10] or thetransport protocols Transmission Control Protocol (TCP) [11] and User DatagramProtocol (UDP) [12]. This OS is implemented using the C language and can run ina lot different platforms, with different microprocessors, for example the Tmote SkyBoard with the MSP430 or the Zolertia Firefly with an ARM Cortex-M3. Contiki-NG was released recently, and it adds several features to the old Contiki OS like anew configuration and logging system, a new lightweight and reliable IPv6 RoutingProtocol for Low-Power and Lossy Networks (RPL) [13] implementation, or a networkadministration shell, and also brings a massive clean up to the code base. It has alsoa much more active community, as its GitHub page [6] shows.

The Contiki-NG OS is a reference in the IoT field. It is widely used as the softwarestack for the constrained devices that conform the network, and it is competing against

5

6 CHAPTER 2. BACKGROUND

other important OSs like FreeRTOS [14] and RIOT [15]. Contiki-NG has been listedin the Eclipse whitepaper about software stacks required for IoT architectures [16]as a reference of open source OS for resource-constrained devices, which shows howpowerful is this OS inside the field.

All these reasons lead to the decision of using this software in the Master’s thesis.The original plan was to use the normal Contiki OS, but Contiki-NG was releasedwhile the project was going on, and it was decided to switch to it in order to be up todate.

There are several interesting features that make this OS suitable for its goal. Someof these features are:

• Full IP [17] Networking: one of the main parts of Contiki-NG is thecommunication stack uIP. This is a complete certified IP stack, which nowadaysis focused on IPv6 [18]. It can work with both transport protocols TCP andUDP. In this thesis UDP is used because it is the transport protocol that runswith CoAP. Contiki-NG provides a full Application Programming Interface (API)with all the functions used to open, connect, send and receive UDP packets.

• Memory Management: Contiki-NG provides a library to manage the RAMmemory by allocating and freeing blocks, which constitutes an efficient way tomanage the memory in constrained devices. It is recommended to use Contiki’sfunctions rather than the standard malloc. Also the OS code footprint is small,which is necessary because devices have also restrictions in the amount of ROM.

• Power Efficiency: this OS is intended to be used in devices that are usuallyoperated with batteries, and therefore their power consumption is a criticalaspect. For this reason, Contiki-NG has been developed with low powerconsumption in mind. Some examples of it are the different low power MACprotocols for reducing the power consumption of the radio, which is one ofthe main parts in this aspect (Section 2.5). Contiki-NG also provides ways tomeasure the power consumption during run time, which can help the device totake decisions or operate in different ways according to it (Section 2.6).

• Implementation of other Communication Protocols: apart from uIP,Contiki-NG contains the implementation of different communication protocolsat different levels of the network stack. An example of this can be 6LowPan[19], which is used to adapt IPv6 packets to the IEEE 802.15.4 protocol usedfor the MAC and Physical layers [5]. Also Contiki implements RPL protocol,which is in charge of building the tree topology and establish the routes insidethe sensor network. Contiki-NG provides a new more lightweight and reliableimplementation of RPL than the old one present in Contiki. But the mostimportant protocols that are going to be used in this thesis are CoAP andLwM2M (Sections 2.3 and 2.4). LwM2M works on top of CoAP and it is theprotocol that is going to be modified in order to implement the Queue Mode.

• Useful Developing Tools: Contiki-NG provides a set of tools to simplify thedevelopment of applications. It has a user-friendly build system, which makes it

2.1. Contiki-NG Operating System 7

easy to compile and upload programs to different hardware platforms, and alsomodify different aspects of the software stack, like the MAC protocol to use. Italso provides a logging tool for debug purposes, and a shell to check and changedifferent parameters during runtime. It also includes a network simulator calledCooja [20], with which a developer can test the applications before they run onactual hardware.

• Libraries: the OS contains a diverse set of libraries that helps to create Contiki-NG applications. These libraries include the management of linked lists andring buffers, the generation of random numbers, and the calculation of CyclicReduncancy Check (CRC) and Integer Fast Fourier Transform (IFFT).

After explaining all the different features of this OS, further details regarding howit is internally implemented are going to be explained, focusing on processes and timersas they can be considered a key part of any Contiki-NG application.

2.1.1 Protothreads, Processes and Events

Before going into detail about the processes, it is necessary to understand what isa protothread and how it works [21]. Protothreads are a programming abstractionwhich aims to reduce the memory overhead of usual threads. In order to do that,they do not have their own memory stack, all of them share the same one. Everytime a context switch occurs, which means that the actual thread is stopped and anew thread is executed, this memory stack for the protothreads is rewound. Thereforethe developer has to declare as static variables the context that wants to be savedor it will be overwritten. The main advantage of this is the amount of memory thatis saved compared to normal threads with their own stack. On the other hand, themain disadvantage is that the developer needs to manually block or yield the threadsby calling defined macros, and save the context. The scheduler cannot perform thecontext switches itself as with normal threads, due to the fact that they do not haveassigned memory stack.

Processes constitute the most important part of the Contiki-NG OS. Every programin Contiki-NG is a process or a set of them running together, and they have two mainparts:

• Process control block: it is a structure that contains information about theprocess, like the name, a pointer to the process thread (the body of the process),and the state of it. This structure is just used by the Contiki-NG kernel tomanage the process, but it is never accessed by user’s code.

• Process thread: it is a protothread which contains the code that runs when theprocess is executed. They always begin with the macro PROCESS_BEGIN() andfinish with the macro PROCESS_END().

In Contiki-NG there are two different execution contexts: the cooperative and thepreemptive, as Figure 2.1 illustrates. The cooperative is where all the processes run and


are executed in a sequential way until they end or until they have to wait for an event,which is done by calling the macros PROCESS_WAIT_EVENT() or PROCESS_YIELD(),among others. So there is no possibility to assign different priorities to differentprocesses and preempt each other, as in Real Time Operating Systems (RTOSs). Thekernel entity in charge of executing the processes is called the process scheduler. Atany time, it invokes the process that has to be executed, by calling the function thatimplements the process thread. On the other hand, the preemptive context is whereinterrupts and callbacks from the real-time timer run. They preempt the processes inthe cooperative context at any point, as soon as they arrive.

Figure 2.1: Processes execution in the Contiki-NG OS.

Contiki-NG can be seen as an event driven OS. Every action in Contiki-NG iscaused by events, since processes are executed when a specific event happens. Thereare two different types of events: asynchronous, which are first put into a queue andthen delivered to the receiving process, and synchronous, which are instantly deliveredto the receiving process. Processes can communicate with each other through eventsor get events from other parts of the OS, like timers. The process scheduler mentionedbefore is the one in charge to run the processes as a response to an event and deliverthis event to it. There are different types of events, each one with a different identifier.Some examples are the PROCESS_EVENT_INIT, which is sent to a process when it isinitiated, and the PROCESS_EVENT_TIMER, which is sent to a process when the eventtimer (Section 2.1.2) has expired.

2.1.2 Timers

Contiki-NG contains a set of timer libraries that can be used to manage time insideprograms. It has one clock module, which handles the system time, and a set of timermodules, which are:

• Timer Module: it provides several functions to set, reset, and restart timers,as well as a function to check if the timer has expired. The application shouldcheck manually whether it has expired. It uses system clock ticks for the count,which means that the count variable is overflowed quickly, and therefore is notsuitable for counting large periods of time.

• STimer Module: the functionality is the same as the previous one, but it usesseconds for the count, allowing much larger periods of time without overflow.

2.2. Network Stack 9

• ETimer Module: this timer generates an event with the identifierPROCESS_EVENT_TIMER when it has expired. Therefore, a process can wait forthis event to do something with a concrete period of time. The etimer has to bestarted before the macro PROCESS_WAIT_EVENT() is called.

• CTimer Module: in this timer module a callback function is executed when thetimer expires. This function is executed in the context of the process that startedthe ctimer, therefore the callback function is executed in the cooperative context,and may need to wait for the execution of another process in this context.

• RTimer Module: this timer also executes a callback function when it hasexpired, but this function is executed in the preemptive context, and therefore itcan preempt any other running processes. This offers a reduced way to schedulereal time tasks, which is not necessary in this project.

2.2 Network Stack

This section shows the network stack that is used in this thesis, and explains brieflythe protocols that conform it. The most important protocols for the development ofthe Queue Mode are explained in detail in the next sections. Figure 2.2 shows thisnetwork stack.

Figure 2.2: Network stack used for the communication in the developed IoT networks.

The different protocols present in the network stack are:

• Lightweight Machine to Machine (LwM2M): it is one of the two protocols thatconform the application layer in this network stack. It is used for devicemanagement, and it is explained in detail in Section 2.4.

• Constrained Application Protocol (CoAP): it is the other protocol that conformsthe application layer, and it is used as a reduced web transfer protocol forconstrained devices. It is explained in more detail in Section 2.3.


• User Datagram Protocol (UDP) [12]: it is the transport layer protocol. It isused to send datagrams between two different hosts on an Internet Protocol (IP)network, in a connection-less way.

• Internet Protocol version 6 (IPv6) [18]: it is the network protocol that providesan identification and location system for computers inside networks and routestraffic across the Internet.

• 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks) [19]: thislayer acts as an intermediary between IPv6 and 802.15.4. Its purpose is to allowconstrained devices in sensor networks to communicate through internet usingthe IP protocol. For this purpose, it defines methods of encapsulation and headercompression to adapt IP packets to the 802.15.4 protocol.

• Carrier Sense Multiple Access (CSMA) [22]: it is the MAC protocol that is usedwhen Queue Mode is enabled. In this protocol the radio is turned on all the timeand every node verifies the absence of any other traffic in the shared mediumbefore transmitting, to avoid collisions.

• TSCH [10]: this is the MAC protocol used in the comparison, when Queue Modeis disabled. It is the standard in IEEE 802.15.4, and its main purpose is toreduce the radio duty cycle by turning off the radio. In order to achieve that,it divides the timeline in different slots that are assigned to transmit, receive, orsleep (Section 2.5).

• IEEE 802.15.4 [5]: it is used as the physical layer. It provides frequency channelsin different ISM (Industrial, Scientific and Medical) bands. There are 16 channelsin 2.4GHz, 10 channels in 915MHz and 1 channel in 868MHz. It has data ratesof 250, 40 and 20Kbps, depending on the configuration.

2.3 Constrained Application Protocol (CoAP)

CoAP is a web transfer protocol designed to be used in constrained devices andnetworks, for Machine-to-Machine (M2M) communication. It was designed in order tobe compatible with Hypertext Transfer Protocol (HTTP) [4] and it consists basicallyon a smaller set of HTTP methods with some other features added to operate in thiskind of networks, like multicast support. This protocol is being specified in the RFC7252 [10].

The protocol is based on the Representational State Transfer (REST) model [3,Chapter 5], where servers have different resources available under their correspondingUniform Resource Identifiers (URIs) and clients can interact with these resources usingthe methods GET, PUT, POST and DELETE. By implementing this well known model,it can be fully compatible with existing HTTP solutions. Only a proxy is neededto translate the requests and responses from one protocol to the other, in order tobe compatible, as the message format of CoAP is slightly different, as Section 2.3.2explains.

2.3. Constrained Application Protocol (CoAP) 11

CoAP is located in the application layer of the network stack, and it works on topof UDP and IPv6. This is another difference with respect to HTTP, which usuallyworks on top of TCP. Therefore CoAP has to deal with some of the TCP features thatUDP lacks, like the acknowledgement of messages in order to confirm the reception ofthem. It can also use Datagram Transport Layer Security (DTLS) [23] on top of UDPfor communicating in a secure way.

The protocol is implemented inside Contiki-NG in an efficient way, and it has alsobeen proven to be energy efficient by using radio duty cycling [24]. This protocol isnot going to be modified in this project, but it has to be understood because LwM2Mworks on top of it.

2.3.1 Messaging Model

CoAP bases its communication on a request/response model between two endpoints,a server and a client, like HTTP. The server has internal resources that are identifiedby an URI, and the client makes different requests in order to interact with them. Theserver is in charge of processing the request, perform the corresponding action, andgenerate the response to inform the client what has happened with its request.

CoAP packets can be transmitted in two different ways:

• Confirmable: it consists on a reliable transmission. The receiver of the messagehas to send an acknowledgement message to the sender to confirm the properreception. If the sender does not get any ACK, it retransmits the packet with anexponential timeout until it gets the confirmation from the receiver or it reachesthe maximum number of possible retransmissions. The receiver can send twodifferent messages: an ACK, which means that the message has been receivedand can be processed correctly, or a RESET, which means that the message hasbeen received but there are some missing context to process it.

• Non-confirmable: this is the non-reliable way. The sender transmits the messagejust once and does not wait for any acknowledgement.

A request packet can be carried in a confirmable or non-confirmable message. Inthe former case, the server has two different options. The first one is to send theresponse directly in the ACK message, which is called piggybacked response. Thesecond one is to first send an empty ACK to tell the client that the message hasarrived properly, and then generate what is called a separate response in a differentmessage, which can be again confirmable or non-confirmable. In order to match therequest with its corresponding separate response, there is a field in the header calledtoken (Section 2.3.2) that has the same value in both messages.

2.3.2 Message Format

CoAP messages are formed by two different parts: a header and a payload. Theheader consists on 4 fixed bytes at the beginning that include: CoAP version, type of


the message (Confirmable, ACK, etc.), token length, the code of the message indicatingthe method of the request or the response code, and the message ID. This fixedheader is followed by a variable-length token, used to bind a request to a responseas Section 2.3.1 explains. Then there is a set of options that can be included, formany purposes. Finally, if the message contains a payload, it is included in the packetstarting with a fixed 0xFF byte to indicate the start point of it.

The options part of the header can be used for different purposes. One of themain ones is to carry the different URI parts, which Section 2.3.3 explains. Also theseoptions can be used to carry out block wise transfers. When a request or a responsedoes not fit in just one CoAP message, it needs to be sent in different messages. Fordoing this, the options Block1 and Block2 can be used, to indicate the position of thecurrent sent block in the total message and the amount of blocks that are left.

The message payload is used to send the concrete information of the specifiedresource. For example, in the response to a GET request, the payload contains theinformation read from the resource. In a PUT request, the payload contains theinformation to be written. There are multiple formats for this payload, such as plaintext, Type-Length-Value (TLV) or JavaScript Object Notation (JSON).

2.3.3 URI scheme

One of the main parts in any web transfer protocol is the URI. It identifies a concreteresource present in the server, so that the clients can interact with it. In CoAP theURI has the following main parts, which are carried in the options field of the CoAPheader:

• URI-Host: identifies the host where the resource is located.

• URI-Port: identifies the transport port that can be used to access the host.

• URI-Path: indicates the specific location of the resource inside the host.

• URI-Query: can be used to include different information inside the URI, forexample the name of the CoAP endpoint.

The CoAP URI is important in order to understand the LwM2M protocol. Themessages that this protocol uses are mapped to normal CoAP messages using thedifferent parts of the URI (Section 2.4).

2.3.4 CoAP Methods and Response Codes

CoAP uses a small set of the standard request methods and response codes from theREST model. The four available request methods are:

• GET: used to read the representation of a concrete resource.

2.4. Lightweight Machine to Machine (LwM2M) 13

• PUT: request the server to update or replace a resource.

• DELETE: for erasing a resource from the server.

• POST: request a server to create a new resource.

In response to this methods, the server sends a code to indicate the client whathas happened with the request. Some examples of these codes are: 2.01 Created,2.05 Content, 4.01 Unauthorized or 5.00 Internal Server Error.

2.4 Lightweight Machine to Machine (LwM2M)

LwM2M is an application layer protocol designed and specified by OMA for devicemanagement in sensor networks and M2M environments [25]. This protocol runs ontop of CoAP (Section 2.3) and uses its REST interface for the communication. LwM2Mextends the resource model to enlarge the features of CoAP, but the use of the RESTmodel makes possible to still integrate it with HTTP.

This protocol defines the communication between a LwM2M server and a LwM2Mclient. The client is usually a sensor node inside a network, and the server canbe any machine located on the Internet. This naming is confusing because both aLwM2M client and server can act as a CoAP client or server, depending on the typeof communication that they are having in each moment. This means that a LwM2Mclient can act as a CoAP client by making requests and receiving responses from theserver, but also as a CoAP server receiving requests from the CoAP client, which inthis case would be the LwM2M server. Moreover, the client has the resources that theserver interacts with, which is also a confusing fact from this naming. So the LwM2Mserver must be understood as the coordinator and the LwM2M client as the node, andnot as the normal client and server naming used in the REST model.

The specification defines four different types of interfaces, which conform the fourdifferent communication scenarios that the client and the server can establish betweenthem, for different purposes. This is explained in the next sections, which also showhow the messages are mapped to the CoAP protocol.

In the following sections, when client or server are mentioned they should beunderstood as the LwM2M ones. When the report refers to a CoAP client or server,the protocol name is specified.

2.4.1 Resource Model

OMA LwM2M defines a simple resource model where all the useful information that theclient holds and the server interacts with consist of resources inside object instances.Figure 2.3 shows an scheme of how this resource model is structured. The clienthas different kinds of objects, which are the definition of a set of resources thathave something in common. Each of these objects has an identifier. An objectexample could be a temperature sensor object or the device object containing all the


important information of the node (manufacturer, version, etc.). These objects arejust a definition, and therefore they need to be instantiated so that the client and theserver can interact with them. This is done by the client, on its own or by a requestfrom the server, creating a new instance with a concrete identifier, and with concretevalues for the resources. It is in this moment when the server can start to interactwith the object instance. One client can have several instances for the same object,for example if the node contains several temperature sensors.

Figure 2.3: Resource model scheme in LwM2M.

LwM2M runs on top of CoAP and uses the URI path of the request in order tointeract with the different objects, instances and resources that the client contains.To interact with a concrete resource, the server request should contain the threeidentifiers in the way <Object_ID/Instance_ID/Resource_ID>. If only an objectinstance with all its resources wants to be requested, then the path should be<Object_ID/Instance_ID>.

It is also important to remark that OMA defines eight default objects, with theidentifiers 0-8, which cannot be used for other purposes. These objects are, amongothers, the Security object, with all the security information for the communication;the Device object, with all the information about the node platform; and the FirmwareUpdate object to update the client’s firmware. By using these objects, the server canmanage different aspects of the client node in an easy way, and this is the reason whyLwM2M is called a device management protocol. By interacting with these resourcesthe server can change several aspects in the device during run time, like the securitykey used in the communication, or the firmware that the node should run.

There are other predefined objects but they are external to OMA. These are calledthe IPSO objects, created by the IPSO Alliance [26]. They define objects that arecommonly used in IoT environments, for example sensors, actuators, and light controls.

With this simple resource model, LwM2M extends the CoAP one to add morefunctionality and adapt it to M2M communications, and also to make it suitable fordevice management.


2.4.2 Bootstrap Interface

Communication in LwM2M is done in four different interfaces, which can be seenas different scenarios, each one with a different purpose. The first one is thebootstrap interface. In this interface, the client communicates with a bootstrap serverin order to get the essential information to start the registration in the LwM2Mserver (Section 2.4.3), for example the server address or the security protocol. Thisinterface is optional, the information to initiate the registration can be configuredin the client before the deployment of the network and then the registration can bemade directly without previous communication with a bootstrap server. This can bedirectly programmed in the node’s firmware, which is called factory bootstrap, or theinformation can be present in an card that the node reads, which is called bootstrapfrom smart card.

In case a bootstrap communication is necessary, there are two options: client-initiated bootstrap and server-initiated bootstrap. In the first one, a request from theclient is necessary to start the communication, and in the second one is the bootstrapserver the one that initiates. Figure 2.4 shows this communication scheme. In thiscase, a client-initiated bootstrap is done. In case the server initiates, the first message(bootstrap request) disappears.

Figure 2.4: Communication scheme in the Bootstrap interface of LwM2M.

This interface consist on five steps:

1. First the Client sends a bootstrap request to initiate the communication. This


is done by sending a POST CoAP message with the URI path /bs and in the URIquery the name of the endpoint.

2. After receiving the request, the bootstrap server checks if it has bootstrapinformation related to that endpoint name, and if true it sends a response code2.04.

3. Then the bootstrap from the server starts. The first action that the bootstrapserver takes is to send a DELETE message to delete previous objects that the clientmay have.

4. After that, the bootstrap server starts creating the necessary objects for doing theregistration to the correspondent server. It sends several PUT or POST messages inorder to do it. The main objects that the bootstrap server needs to create are thesecurity object, with all the security information that is necessary (type, keys,certificates, etc.) and the server object, which contains the important informationabout the server (address, port, etc.). All these messages are responded by theclient with the response codes that tell if the creation has been successful or not.

5. When the bootstrap server has finished creating the objects, it sends a bootstrapfinished message. This message consists of a POST message with the URI path/bs.

After doing this exchange of messages, the client has all the necessary informationto do the registration in its corresponding server.

2.4.3 Client Registration Interface

This interface is used by a client to register in a server, de-register or update theregistration information. This step is mandatory to start the communication usingthe LwM2M protocol. By this registration, the client provides the server with thenecessary information to communicate with it, like the endpoint name, and alsospecifies the objects that it supports and the instances that it has, in a directory format(<Object_ID/Instance_ID>). So after doing this, the server knows the resourcesthat the client contains and is able to start interacting with them. A server can havedifferent clients registered on it at the same time, and a client can be registered indifferent servers.

In this interface the client is always the one who starts the communication witha register message, which contains all the necessary information already mentioned.This register message contains four main parameters in the query:

• The endpoint client name.

• The lifetime, which determines how long the server will keep the client registered.If after this time the client doesn’t send an update message, it is removed fromthe server’s registered clients list, as it interprets that the client is no longeravailable.


• The LwM2M version.

• The binding mode. This parameter is not mandatory, but it’s really importantfor this project because it determines if the Queue Mode is enabled or not(Section 2.4.6). This parameter is also used to indicate the transport protocolthat runs under CoAP (U for UDP and S for SMS). In case the Queue Mode isused, a Q is added to the binding mode.

Figure 2.5 shows the message exchange in this interface. First, the client sends aRegister message with all the parameters mentioned above. This message consists ofa POST with the URI path /rd, the query with all these parameters and the payloadwith the object instances. The server responds with the corresponding response codeincluding the location, which is an identifier for this client, and then it saves the clientinformation in the registered clients list. This location must be used by the client whendoing an update or a de-registration. Then, the next interface can start (Section 2.4.4).

Figure 2.5: Communication scheme in the Client Registration interface of LwM2M.

Before the lifetime expires, if the client wants to keep registered in the server, itneeds to send an Update message with a new lifetime. This message is again a POSTwith the URI path /rd/"location" and a query with the new lifetime. If the client


does not send this message, the server de-registers it. Finally, if the client wants tode-register itself manually, it sends a de-register message, consisting of a DELETE withthe path /rd/"location".

2.4.4 Device Management and Service Enablement Interface

This is the interface where, after knowing all the client necessary information, theserver can start submitting requests to the client to interact with its resources. Thereare six different types of operations that a server can do. Figure 2.6 shows someexamples of these operations.

Figure 2.6: Communication scheme in the Device Management and Service Enablementinterface of LwM2M.

These operations can be listed in:

• Read: this operation is used to read the value of a full object, a concrete objectinstance or a concrete resource from the client. This is performed by sending aGET message to the specific path of the resource, instance, or object. The clientsends a response with the content requested in the payload. This content can besent in different formats, for example text plain, TLV, or JSON.

• Discover: this operation is used by the server to know all the objects that theclient has, or all the attributes that a concrete object has. This is also done witha GET message.

• Create: with this operation, the server can create a new object in the client. Itsends a PUT or a POST message with the object id to be created as the URI path.


• Write: it is used to change the value of one or more resources in an object. Itconsists of a PUT or POST with the path to the concrete resource and the contentto be written in the payload.

• Execute: there are some resources that are used to perform actions inside theclient. To execute these actions, the server can send an execute operation to theconcrete object, which consists of a POST message to the resource path.

• Delete: used to remove an object instance in the client. It consists of a DELETEmessage to the object instance path.

With these operations, the server can manage the different client nodes. It can getsome useful information from the client, like a read operation to the sensor temperatureobject, or execute a concrete action in the client, like activate an actuator. Also, usingthe defined objects, it can also update the firmware of the client by creating a newfirmware object, or change the security parameters of the communication by writingdifferent values in these resources. This is what makes LwM2M a device managementprotocol.

2.4.5 Information Reporting Interface

This interface is used by the server to observe a concrete resource in a client’s object.The client sends the new value of the resource whenever it changes, or when the periodexpires if it is a periodic resource. So this interface is useful for the server to keep trackof a concrete resource. Figure 2.7 presents the communication scheme.

It consists of three different parts:

• Observe: with this message the server tells the client which resource it wants toobserve. It is a GET message with the observe option set to 0 and the path to thecorresponding resource. In this case the token part of the CoAP header needs tobe used in order to link the future notifications with this observation. The clientsends a response with the content of the resource at that moment, and gets readyto send notifications every time the resource changes in the future.

• Notify: in this part, the client sends notifications with new values of the resourceto the server. A notification consists of a response message with the code2.05 Content, the same token as the observe message, the observe option set to0, and the value of the resource in the payload. To perform a notification thereare different conditions. There is a minimum period in which if the resource’svalue changes, the notification is not sent. There is also a maximum period when,if the value has not changed yet, a notification is sent anyway. There are alsosome possible conditions of the type greater than, lower than, or step, whichdetermines if the value’s change is enough to be notified. All these parameterscan be set by the server in what is called a write attributes operation, whichconsists of a PUT message from the server with all this parameters in the query.The client saves them to use in the information reporting interface.


Figure 2.7: Communication scheme in the Information Reporting interface of LwM2M.

• Cancel observation: with this message the server tells the client that it wants tostop observing a concrete resource. It consists of a GET message with the observeoption set to 1 and the path to the resource.

This interface can be useful in the context of IoT. A typical example is amonitoring scenario where the server wants to keep track of specific parameters, likethe temperature of a room or the state of a mechanical structure. The server cansend an observe message to the object inside the node, and then when the parameterchanges (and this change fulfils the conditions set for a notification) or the periodexpires, the client sends a notification.

2.4.6 Queue Mode

This is the main topic of this Thesis. Queue Mode is a part of the LwM2M protocolcreated with the goal of saving energy at the client side. Its purpose is to allow theclient to sleep for long periods of time, when the server cannot make any requests toit. The specification of this low power mode is quite brief and there are not manyimplementations and evaluations of it.

In Queue Mode, when the client registers with the server, it includes the character


’Q’ in the binding mode inside the query. This has to be interpreted by the server as aregistration with the Queue Mode enabled, meaning that it would not be able to sendrequests to the client at any time. Instead, it has to wait for a message from the clienttelling that it is awake again, and then it can make these requests. In this time wherethe client is sleeping it is up to the server what to do with the requests that can begenerated. One option would be that these requests can be saved in a queue, which isthe reason for the naming of this mode, and then sent them when the client is awakeagain. But this is not a part of the specification, this queue is not mandatory and theapplication running in the server can manage it in the way it wants.

This mode is implemented by making use of the registration interface, changingtwo aspects of it. The first thing is to include the Queue Mode binding mode in theregistration message. The second is to send an update message when the client isawake and it is ready to process incoming requests. This update message can be alsoused to update the life time or other aspects of the session as in normal mode, but hasto be interpreted by the server as a change in the client state, from sleeping to awake.

Figure 2.8: Communication scheme using LwM2M protocol with Queue Mode enabled.

Queue Mode can operate in both interfaces, Device Management and ServiceEnablement, and Information Interface. The first one can be divided in three steps,


as Figure 2.8 shows:

• The client sends the registration message with ’Q’ as the binding mode (’UQ’ ifit uses UDP).

• The client can go to sleep, but first it has to wait some time in order to receivenew server requests. This time is going to be called client awake time in therest of the report. The specification recommends to wait for the constant timeMAX_TRANSMIT_WAIT present in the CoAP protocol. By default this time is 93seconds, which is not efficient for low power consumption in the client nodes, asthe radio has to be turned on all this time. This time has been the object ofan open discussion in the OMA LwM2M GitHub page 1. Some people suggestedto send a message from the server telling that it has no more requests. Withthis, the 93 seconds would be only a worst case when this message is lost, andtherefore the client saves energy in most of the cases. This is not included in thespecification yet, so there can be different approaches about how much time theclient should stay awake, as the MAX_TRANSMIT_WAIT is only a recommendation.After this time, the client can go to sleep, put the CPU in low power mode andturn off the radio.

• At some point, the clients wakes up and sends an update message to the server,informing that it can receive and process some requests. Then the server cancommunicate. After processing these requests, the client can go to sleep again,after waiting for the client awake time, as in step 2. There is no specificationabout how long the sleeping time should be, or who determines it: the client, theserver, or an agreement between them.

For the information interface, the operation is very similar. The only thing thatchanges is that the client is woken up by a notification event, then it sends theupdate message to tell the server that it is awake, gets the ACK response, sendsthe notifications, and then it can receive requests from the server.

With this mode a large amount of energy can be saved by allowing the client tosleep for long periods of time. This mode can be useful when there are no criticalresources that the server needs to know very often, for example the temperature andhumidity of a room. If there are critical resources that change often, this mode wouldalso work if the server is observing them, but it does not save too much energy if theclient is woken up all the time. Moreover, it would consume more energy because theclient has to send the update messages.

2.5 Low Power MACs in Contiki

The MAC layer in the communication protocol stack is the layer between thenetwork and the physical ones. It provides addressing and channel access control

1OMA LwM2M GitHub Page. Issue "Queue mode and timeout for offline": https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues/98. Visited: 01/11/2017

https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues/98

https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues/98

2.5. Low Power MACs in Contiki 23

in environments where there is a shared medium, like the radio spectrum in a WSN.In Contiki-NG there are different implemented MAC protocols, for example CSMA orTSCH. The first one constitutes an always on protocol where the radio is in listeningmode all the time, and it checks if the shared medium is occupied when it tries tosend a new message. As the radio is turned on all the time, its power consumption ishigh. It is the MAC protocol used when the Queue Mode is enabled, in which case theradio is turned off manually by the application layer. On the other hand, Contiki-NGcontains TSCH, which constitutes a way of radio duty cycling as a low power strategyat the MAC level of the network stack. The old Contiki OS included another radioduty cycling protocol called ContikiMAC [27], but it has not been ported to Contiki-NG, as it is not a standard protocol. Therefore, TSCH is the protocol chosen to makethe comparison with Queue Mode, also because it has been already proven that itsenergy efficiency is higher than CSMA and ContikiMAC [28], and it is the standardMAC layer in IEEE 802.15.4. Then, the goal of the Master’s thesis is to compare andsee if the LwM2M protocol using CSMA with Queue Mode enabled can achieve betterenergy efficiency than TSCH. Therefore, this protocol is explained in this section forthe reader to have a good understanding of it.

TSCH is a MAC layer which offers a globally synchronized network where nodescan turn off the radio for fixed periods of time. The time is divided into differenttimeslots which are usually 10 ms long, and each slot is dedicated for transmitting,receiving, or sleeping. There can be several slots where a node is transmitting differentkinds of traffic. With this strategy, the nodes can sleep and turn off their radios a largeamount of the time. This timeslots are grouped into slotframes with a specific length,and each slotframe is repeated periodically. Also when a node wants to communicate,a channel hopping is done, which means that the communication is produced in adifferent frequency channel for different occurrences of the same slot. Then a time slothas two main parameters: the time offset indicating the position inside the slotframein which the slot is located, and the channel offset, indicating the frequency of thecommunication. Figure 2.9 shows a simple example of two nodes communicating witheach other using TSCH. Each time the slotframe is repeated, the communication (TXand RX) happens at a different frequency channel.

Figure 2.9: TSCH slotframe example for the communication between two nodes.

This layer is successfully implemented in Contiki-NG, using timer interrupts anddoing all the communication in the callback functions. To communicate with upperlayers, a ring buffer is used to queue the received packets or the packets to transmit.Then, the upper layer, which is usually IPv6, puts the packets that wants to transmit


in the outgoing queue, and read the packets from the incoming queue. This queue-based implementation favours the portability of the TSCH implementation to otherOSs.

In TSCH the time synchronization is important because nodes have to communicatewith each other at a concrete time in a synchronous way, and therefore there cannotbe a clock drift between them. The time precision needs to be at the micro-secondlevel. Clock drift is implicit in the crystal oscillators and cannot be avoided, so away of re-synchronization is necessary. This time re-synchronization is done whena frame or an ACK is received from a timer source, which is usually a parent nodein the network architecture. The receiving node compares the reception time withthe expected time and adjusts its clock to it. The Contiki-NG implementation alsoincludes an adaptive way, where the nodes learn from previous time drifts and adjustthe clock automatically when performing a wake up.

Scheduling is also a main part of this MAC protocol, which determines how theslots are configured and distributed in time on any node. This has to be done inan intelligent way so that the nodes can communicate with each other in the sameslot without interfering with other ones. In the Contiki-NG implementation there arebasically two types of scheduling:

• Minimal configuration is a simple schedule. All the nodes have a singletimeslot inside a single slotframe where all the communication happens, based oncontention. Therefore this is not a very efficient way of communicating, becauseif there are many nodes in the network, there can be high interferences. That isthe reason why Orchestra was created.

• Orchestra [29] works together with RPL, making it possible for nodes to computetheir own schedules locally based on the structure of the network. The Orchestraschedule gives one slot for each kind of communication that a node needs in theRPL architecture, which are: a common slot for all nodes in the network forRPL signalling, a unicast slot from every node to its parent, several slots froma node to its children, and a dedicated broadcast slot from every node to sendTSCH beacons. With these four types of slots, all the communication can takeplace in the network. In order to compute the schedules locally on every node,the coordinates (time and frequency) of each slot are based on the sender orreceiving identifier, therefore no third party is needed. Orchestra also makes itpossible to maintain several slotframes for each kind of traffic that the nodesare sharing. For example there can be one slotframe for application traffic likeLwM2M and another for RPL traffic.

In relation to power consumption, TSCH allows the nodes to use an efficient wayof radio duty cycling. This means that the radio can be turned off in the slots that arenot used to communicate, and it only needs to be turned on when a slot with somekind of communication arrives, like to send a packet or to listen for possible incomingmessages. Also inside every slot, TSCH does not turn on the radio all the duration ofit to reduce even more the energy consumption. In the transmitting slots, the radiois turned on only if there is a packet placed in the queue that needs to be sent. In

2.6. Measuring Energy Consumption in Contiki 25

the receiving slots, the radio is turned on with a guard time of ± 1.2 ms as default.This ± indicates that it turns on the radio 1.2 ms before the starting point of the slot,until 1.2 ms after this point. If there is a packet reception, then the radio remains onuntil the end of this packet, but if there is no packet reception the radio is turned offimmediately. So this strategy allows to reach a much lower radio duty cycle.

TSCH is a more efficient protocol than for example ContikiMAC, in which theradio is also duty cycled, but without any schedule. With ContikiMAC, a node thatwants to send a message retransmits this message several times until the receiver tellsthat it’s awake with an ACK message. On the contrary, in TSCH there is a schedule,specially efficient if Orchestra is used, when the nodes know exactly when they cancommunicate, so they can wake up only on the dedicated slots, and they only need tosend a packet once.

2.6 Measuring Energy Consumption in Contiki

For this project, a tool for measuring the energy consumption of the hardware nodesis needed in order to perform the evaluation of LwM2M using different low powermethods, by comparing them. The most accurate way to determine the powerconsumption of a node is to measure the electric current at its input and the batteryvoltage. This can be done by adding additional hardware in the node board. But ithas been proved [30] that the cost of this module would be similar to the cost of thenode itself, and therefore it is not an efficient way to do it. Also it makes impossibleto use standard hardware boards directly, and some hardware should be developed,which is out of the scope of this project.

Therefore, a software tool has been developed for Contiki-NG OS, to avoid all thedifficulties of measuring the power consumption with dedicated hardware [31]. Thistool has been proved to be efficient and accurate. It does not add any additional costneither much memory footprint. And it is also easy to use by just adding a few linesof code in the hardware drivers. This tool is also an advantage with respect to thementioned hardware tools, which is that it is possible to measure the consumption ofhardware parts in isolation, like the radio or the CPU, and not only the total energyconsumption of the whole device.

The method is based on measuring the time in which a concrete hardwarecomponent is on, and then take its current consumption from the datasheet, andmultiply. The energy model used is:

E

V= Imtm + Iltl + Ittt + Irtr +

N∑i=1

Icitci (2.1)

The symbol I stands for the electric current, and t for the time that a concretehardware component is on. Then the subindex m stands for the microprocessor inactive mode, l for the microprocessor in low power mode, t for the radio transmitmode, r for the radio in reception mode, and ci for other additional components such


as sensors or LEDs. So with this model, all the components are taken into accountand contribute to the total energy consumption.

This software method is implemented inside Contiki-NG OS in the files"energest.[hc]". This module maintains a table with all the times that the differentcomponents are turned on. Then, in the device driver, before turning on a specificcomponent, the macro ENERGEST_ON(type) is called, which saves a timestamp usingthe function RTIMER_NOW() that returns the system time in ticks. This macro gets thetype of component that is turned on. When the same component is turned off again,the macro ENERGEST_OFF(type) is called, the difference with the previous timestamp iscalculated, and the time is added to the table in the entry of the hardware component.Hence, this table contains all the time that all the devices have been turned on,consuming energy.

All this code is already included in the device drivers of the different platformssupported by Contiki-NG, so the developer just has to enable the module by definingthe constant ENERGEST_CONF_ON as 1. Then, in the main application, some functionscan be called to obtain these times, multiply them by the known current consumption,and determine the energy consumption.

This is the tool that is used in this project, as it has been proven to be accurateenough [31], and it is suitable to use. With it, the energy consumption of the nodes isgoing to be measured in several scenarios using the different low power communicationprotocols.

Chapter 3

Queue Mode Implementation at theClient Side

The first part of the project is to implement the Queue Mode at the client side of theLwM2M protocol, inside the code that will run in the nodes. For the implementation,the existing Swedish Institute of Computer Science (SICS)’s LwM2M client softwareis used and modified to add the Queue Mode operation. This code is available inGitHub with an open-source BSD licence [32]. It was firstly designed to run inContiki, but it has also been rewritten to be portable to other operating systems, andeven to be runnable in a normal Linux machine, which facilitates the development.This portability makes it easy to use this software inside Contiki-NG, with just smallchanges in order to build it. This code needs to be changed as a part of this projectto support the Queue Mode.

All the sources files are included inside the directory contiki-ng/os/services/oma-lwm2m. There are two main parts in this LwM2M client software. The first one isthe LwM2M Resource Directory (RD) client, which manages the bootstrap and theregistration interfaces. It is called resource directory because when it registers withthe server, it specifies the resources that it has in a directory way, with the path<Object_ID/Instance_ID/Resource_ID>. It is implemented in the files lwm2m-rd-client.[hc] and all the functionality is done with a Finite State Machine (FSM) thatexecutes periodically using a timer. The second important part is the LwM2M engine,which manages the reception and processing of requests from the server, and also is incharge of sending the responses. This means that the engine mainly performs the othertwo interfaces, device management and service enablement interface, and informationinterface. But it does not only manage this two interfaces, it is always running inparallel with the RD client, processing also the requests that the server does in thebootstrap phase, for example. It is implemented in the files lwm2m-engine.[hc]. All thelogic is done inside a handler that is executed every time a new CoAP packet arrives,by the CoAP engine that runs bellow. Apart from these two, there are other sourcefiles for different purposes inside the LwM2M directory. Some files implement thestandard LwM2M objects (server, security, firmware, etc) and other files implementthe parsing of the different payload formats (plain-text, TLV, and JSON).

27

28 CHAPTER 3. QUEUE MODE IMPLEMENTATION AT THE CLIENT SIDE

For implementing the Queue Mode, the main parts that need a change to supportit are these two: the RD client and the engine, which are the ones that manage thefour communication interfaces present in LwM2M.

3.1 Implementation in the LwM2M RD client

The RD client is the part of the software in charge of the bootstrap and the registrationinterfaces, which have been explained in Section 2.4. Therefore it controls the exchangeof messages with the server to perform the corresponding actions defined in theseinterfaces. Queue Mode does not use the bootstrap interface, and therefore this partof the software does not need to be changed. For the registration interface, two mainchanges are necessary:

• Send the ’Q’ binding mode in the registration message.

• Send a registration update message every time the client is awake and can receiveand process new requests. After sending this, the client needs to wait for the clientawake time to be sure that there are no more requests. When this time expires,it can go to sleep. As the specification only gives a recommendation for thiswaiting time, which is 93 seconds, a design decision must be taken in order toset this time because it is too long for energy efficiency purposes. As this sectionexplains in detail later, a dynamic adaptation of this time has been implemented,based on measuring the time between two consecutive server requests.

The RD client is implemented as an FSM, which Figure 3.1 shows. This FSM isexecuted in a periodic way using the network timer (ntimer). This timer is simply anabstraction for not using Contiki’s timers as default, and therefore not restricting thissoftware to run on top of it. This abstraction makes it possible to port the LwM2Msoftware to other OSs. The network timer has to be implemented for every OS that willrun the LwM2M software. If this software is run inside Contiki-NG, as it is the caseof this thesis, the ntimer is implemented just by using the event timer (Section 2.1.2).

3.1.1 Finite State Machine operation without Queue Mode

Figure 3.1 illustrates how the FSM without the Queue Mode implementation works.

The first two states of the FSM (INIT and WAIT_NETWORK) are used just to connectthe node to the internet, and wait until it has network access, through a border router.After this, if the bootstrap phase is necessary, it moves to the state DO_BOOTSTRAP forsending the corresponding message to the bootstrap server (Section 2.4.2). Then itmoves to an intermediate state just for waiting for the server to do the bootstrapphase, and send the response. When the response from the server arrives, a callbackis executed by the CoAP engine, and the FSM is moved to the BOOTSTRAP_DONE state.In this state, the client checks if all the necessary objects have been created correctly,and moves the FSM to the DO_REGISTRATION state to start the registration phase.Here the client sends the registration message to the server and then waits for the

3.1. Implementation in the LwM2M RD client 29

Figure 3.1: Finite state machine implementing the RD client.

response. Once this response arrives, the FSM is moved to the REGISTRATION_DONEstate. It is at this moment when the client is registered in the server and it is readyto receive requests, according to the device management and service enablement orthe information interfaces, which are processed by the LwM2M engine. The client willremain in this state, sending a registration update message every time it detects thatthe lifetime will expire. Actually, it sends one update message when it detects that halfof the lifetime is consumed, just to be sure that it is not deregistered from the server.Therefore, the period of the FSM has to be lower than the lifetime in order to sendthe update message at a proper time. If the client wants to force a de-registration, itis moved to the state DEREGISTER to send the corresponding message.

If at any point the server responds with an error message, the client is driven tothe INIT state again for trying to restart the registration process. For simplicity thesearrows have not been included in the figure.

3.1.2 Finite State Machine operation with Queue Mode

For implementing the Queue Mode inside this software as part of this Master’s thesis,the main change in the RD client is the addition of two new states in the FSM tohandle it, as Figure 3.2 shows.

In particular these states are Q_MODE_WAITING and Q_MODE_SEND_UPDATE, whichare highlighted in grey. After sending the registration message with the binding modeset as ’Q’ in the DO_REGISTRATION state and receiving the corresponding response, themachine is moved to the Q_MODE_WAITING state. In this state the client waits for theclient awake time to receive new server requests, and when this time ends, it goes tosleep. When the client enters this state, it stops the periodic ntimer so that the FSM


Figure 3.2: Finite state machine implementing the RD client with Queue Mode operation.

is not triggered in a periodic way, and starts another ntimer with the client awaketime as expiration time. This timer is restarted by the LwM2M engine every time anew request arrives, since the client needs to wait for this time after the last receivedrequest. When this timer expires, meaning that there are no new requests, a callbackfunction is called and the client is put in sleep mode, turning off the radio. Therefore,in this implementation the control of the client’s state (awake or sleeping) is done bythis part of the software.

When Queue Mode is enabled, no radio duty cycling at MAC level is used. Theradio is turned on and off according to the Queue Mode operation, at the same timeas the CPU is changed between active and Low Power Mode (LPM). For enteringthe sleep mode, only the radio is necessary to be turned off, because Contiki-NGautomatically puts the CPU in LPM when there are no processes to run. The networkstack process run at some time instants, trying to send some packets, for example forthe RPL protocol, and therefore putting the CPU in active mode. Also some otherprocess can consume CPU active time, like the Energest module to measure energyconsumption. But these processes only consume ta few milliseconds of CPU, so it isconsidered as a valid option to keep this operation in relation to CPU. The problemthat the network stack executions create is that, as how the MAC layers and radiodrivers present in Contiki-NG are implemented, when the radio is turned off manuallyby the RD client, it is turned on again by the network stack when a new packet wantsto be sent, and it is not turned off again after sending it. The result of this is thatthe radio remains listening all the time, consuming a lot of energy. To avoid this, asimple flag is added in the CSMA driver, which is enabled when the off() function iscalled, and then the functions for sending packets do not execute if this flag is active.For turning the radio on again, the on() function needs to be called by the RD clientwhen waking up.

3.1. Implementation in the LwM2M RD client 31

So when the client awake time has expired, the radio is turned off and the ntimer incharge of triggering the periodic FSM is reset with the time to sleep as an expirationtime, to fire the FSM again when it is time to wake up. When this timer expires,the FSM is moved into the Q_MODE_SEND_UPDATE for sending the update message tothe server informing that it can receive requests. When the server responds, currentstate is changed again to Q_MODE_WAITING and the process starts again. Therefore,by moving between this two states the registration interface with the Queue Mode ishandled, and also the action of driving of the node into sleep mode.

3.1.3 Design and implementation of the client awake time

As it has been mentioned before, the client awake time, which is the time that the clientstays awake since the last received request, is not specified and only recommended bythe OMA LwM2M specification. The problem is that the recommended time is toolarge for low energy consumption purposes, so something different needs to be designed.What has been implemented in this thesis is an adaptive way of setting this time, inorder to be efficient and to not wait for a longer time than needed. This has a highimpact on the power consumption, because all the time that the node is waiting fornew requests, the radio is turned on in listening mode. So this time should be reducedas much as possible.

The design that has been developed is based on choosing this time in an adaptiveway. The idea is to keep track of the time that the server needs between thetransmission of two consecutive requests, which means since it sends one request untilit sends the next one, after the client’s response. If this time is determined, then theclient can go to sleep after it, assuming that there are no new requests because theserver would have already sent them after this time. For implementing this algorithm,the LwM2M engine measures the time between two consecutive received requests fromthe server, saves this times in a fixed size list, to have a window of the last times, andfinally adapts the awake time accordingly. The size of this list is decided to be set toten which is enough for not increasing the memory usage too much, and therefore thelast ten times are taken into account. The client awake time is determined taking themaximum value of these times, and adding a margin to it as a percentage.

This margin needs to be set in a safe enough way, because it determines howthe client would adapt if the network conditions change. If at some point of thecommunication the time between two consecutive requests increases more than thismargin, for example due to a more congested network or a more busy server, the clientwould go to sleep before the requests can reach it. As the client does not get anyrequest, no time between two consecutive requests can be measured, then window oftimes is not updated and the client awake time is not adapted. This causes that norequest can reach the client before it goes to sleep, so it becomes unreachable unlessthe conditions of the network change back to the initial ones.

In the Evaluation chapter, this dynamic adaptation is also tested to see if it is safeenough, or if it is better to have a fixed time, low enough to save energy, but muchsafer than the dynamic one.


3.2 Implementation in the LwM2M engine

The LwM2M engine is the part of the software in charge to process the requests fromthe server and send the corresponding response. This is done by using a callbackfunction that is executed every time a new CoAP packet arrives, by the CoAP enginethat runs in the network stack. In this callback, the method and the path of therequest are checked, and then an action is performed according to it. These actionscould be any of the ones that Section 2.4 explains.

This part of the software does not need many changes for implementing the QueueMode. One minor needed feature is to restart the timer that holds the client awaketime when a new request is received if the RD client is in the Q_MODE_WAITING state,which is known by a flag set by the RD client code. This is programmed by just callingthe restart function of the network timer.

3.2.1 Design and implementation of the Information Interface with QueueMode

The LwM2M engine is also in charge of the information interface, which means sendingthe notifications to the server when it is observing any resources. This engine acts asan intermediary between the CoAP engine and the object implementation. This meansthat it is the object software that should know when to send a notification and call theLwM2M engine for it, which creates the path according to the instance and resource,and gives it to the CoAP engine to perform the notification. The CoAP engine checksin the saved list of observed resources if this resource has any observers, and in thatcase it sends the notification. So it is the CoAP engine that checks if there are observersor not, whereas the object implementations and the LwM2M do not care about it.

For implementing the information interface together with Queue Mode, the onlything that is different is that if an event is created while the client is sleeping, then theclient should wake up, send the update message, and then send the notification (seeSection 2.4.6). For implementing this, whenever an object tries to send a notification,first the LwM2M engine executes manually (not by a timer callback) the RD clientFSM and put its state into Q_MODE_SEND_UPDATE for sending the update message, andthen it sends the notification. But before waking up the client and executing the FSM,the engine needs to check if there are any observers for the resource, otherwise it wouldbe pointless and energy would be wasted. For doing that, the list of observed resourcesfrom the CoAP engine is checked in order to find if the concrete resource is inside it.

When implementing this, a particular problem was detected. When the clientsends the update message after waking up by a notification event, it has to wait forthe server response before sending any notifications. But in this particular momentwhen the client is waiting for the response, other resources can create a notificationevent, and as the client is woken up, the engine sends these notifications directly tothe server before receiving the response. Figure 3.3 (a) illustrates this problem. Thesolution implemented in this thesis (Figure 3.3 (b)) is to save in a queue, implementedas a linked list, all the notifications that are created at this point, and send all of them

3.2. Implementation in the LwM2M engine 33

once the response from the server has arrived. With this, the protocol specification isrespected.

(a) Problem.

(b) Solution.

Figure 3.3: Problem (a) and solution (b) in the information interface when using QueueMode.

In the original implementation of this LwM2M software present in the SICS’software [32], every observed resource is identified by a constant array of twentycharacters, to allow having 6 digits for object, instance, and resource identifiers,separated by two slashes (object_id/instance_id/resource_id). The problem withthese constant arrays is that they contain 20 bytes, so only a few of them can bestored in the linked list inside the RAM memory. This translates in the fact thatmany notification events can be lost in this short period of time when the client iswaiting for the response, because they do not fit in the memory. The implementedsolution to this problem is to translate the character array paths to an array of three16 bit integers, one for each identifier, before storing them. With this, every generatedevent is just 6 bytes long.


Even with this reduction in the size, not too many events can be saved, just aroundten, of course depending on the hardware platform. Therefore, a policy is applied whenthe queue is full and a new event is generated. The rules that have been designed forthis policy, with the goal of making it as fair as possible, are, applied in order:

1. If there are any other events from the same resource, delete the oldest one andinsert the new event.

2. If there are more than one event from other resource saved, delete the oldest oneand insert the new event.

3. If the list is full with events from different resources, delete the oldest one andinsert the new event.

With these rules applied in the correct order, the queue is managed in a fair way,and the newest events from all resources are always kept.

All the implementation of this queue is done in two separate files, lwm2m-notification-list.[hc], to make it easier for future changes and to not include all thiscode inside the LwM2M engine code.

At the moment when this report is done, the notifications management in theLwM2M implementation was not finished, and only a limited version is implemented,where all the logic resides in the CoAP engine and the object’s software, andthe LwM2M is just an intermediary between both of them. Also, the currentimplementation uses the large character arrays to identify the resource events. Thisis presumed to change in the near future, and all the logic will be implemented inthe LwM2M engine, making it more easy to develop new objects, and making it moreefficient than the CoAP engine does. For this implementation, the translation to 16-bitinteger arrays and the handling of the notification’s queue can be used.

3.3 The Queue Mode Object

The last part of the client implementation done in this thesis is to create an objectinside the LwM2M’s resource model for managing the Queue Mode. This object hastwo different purposes: select the time to sleep and the client awake time, and reportsome general statistics about power consumption. For that purposes, it has severalresources that Table 3.1 shows.

As it has been explained, there are no specifications about the time the client shouldsleep and about the time it should stay awake. This could be done by some exchangeof messages between the client and the server to reach an agreement, because for manyapplications it would not make sense that these times are directly programmed insidethe client’s software. It is necessary that the server can take part of this decision, forthe good performance of the whole IoT application. For example for some applicationit could be fine for the server that the client sleeps for a minute and that it uses thedynamic adaptation for the client awake time (Section 3.1), but in other applications

3.3. The Queue Mode Object 35

Table 3.1: Resources present in the Queue Mode object.

Resource Operations PurposeSleeping time Read/Write Set the client’s sleep time.Client Awake Time Read/Write Set the client awake time.Dynamic Adaptation Flag Read/Write Enable and disable the dynamic adaptation.Cycle CPU time Read CPU in active mode in the last cycle.Cycle LPM time Read CPU in low power mode in the last cycle.Cycle TX time Read Radio transmitting in the last cycle.Cycle RX time Read Radio listening in the last cycle.Total energy Read Total energy consumption since booting.

the server might need the client awake every ten seconds and it needs it to stay up forfive seconds because it is a more demanding application.

Three basic resources are included in the Queue Mode object, that are readableand writeable. The purpose of these resources is to give the server the capability todecide the sleeping and the waiting times. The first one is precisely the time to sleep,for the server to decide it. Of course the client can also change this value, so bothhave power in the decision. The second one is a flag to enable or disable the dynamicadaptation of the client awake time, for the server to decide if this should be appliedor if a fixed time should be used. The third one is precisely the client awake time,which can be fixed or dynamically changed, depending on the value of the previouslymentioned flag.

Apart from these resources, the client can also report some statistics about thepower consumption. Five resources are present, which are the times where the fourmain hardware parts are turned on in the last cycle, and the total energy consumedfrom the booting. The first four contain the time where the CPU has been in activemode and in low power mode, and the time that the radio has been in listening andtransmitting mode. These four actions are the ones that consume most energy in thenode, but if some sensors, actuators or other hardware devices are added to it, theycan be included easily in the queue object. The times are computed for every cycle,which is the time between two consecutive client waking up instants. Therefore, thistime includes the two main parts of the Queue Mode. First, the moment when theclient is receiving and processing requests from the server, with the radio in listeningmode all the time and transmitting for short times to send the responses, and the CPUis mainly in active mode. And second, the time when the client is sleeping, when theradio is completely off and the CPU in low power mode. A good picture of the QueueMode functionality can be obtained with these four resources. The fifth resource is thetotal energy consumed since the node was turned on. It is computed on every cycleby multiplying the obtained times by the current consumption, and accumulating theresult in the resource value. Then, this resource represents the total energy/voltagesince booting the node.

These statistics have two different purposes. The first one is just for the debuggingof the Queue Mode implementation inside this project. The second one is to take


some decisions about the client awake time or the time to sleep according to theenergy that has been consumed. For example if the client or the server see that theenergy consumption is increasing too fast, they can change the sleeping time and puta higher one, in order to save more energy. In this moment nothing has been done inthis sense, because the focus for now is to have a basic implementation according tothe specification, but maybe in the future something can be done in this direction tohave an intelligent sleeping node.

Chapter 4

Queue Mode Implementation at theServer Side

In this section, the implementation of the Queue Mode at the server side done as apart of the thesis is explained in detail. After implementing the Queue Mode in theclient side, the next part of the project is to implement it in the server side. This isnecessary in order to perform the main goal of this thesis, which is the evaluation of theQueue Mode in comparison with other low power strategies. For this implementation,Eclipse Leshan [7] code is used and modified to achieve the desired performance of thisQueue Mode. Leshan is an OMA LwM2M client and server implementation writtenin Java code. It is an open source project created by the Eclipse foundation in 2014and provides a set of libraries in order to make it easy for a future developer tomake its own client, server, or bootstrap server. It also gives example code of howto implement them, for demonstrations and testing. The Leshan code runs on top ofEclipse Californium [33], which is an implementation of the CoAP protocol that is alsowritten in Java. Leshan uses Californium in order to send and receive CoAP packets.

The server code can be divided in three different layers: the Californium corerunning as the bottom layer, the LwM2M core running on top of Californium, anda web application running as the upper layer. The web application is used justas an example and contains different buttons for making requests to the registeredclient, using the functions present in the LwM2M core. This core provides differentlibraries for supporting the different features that the protocol has. These features are,among others, the client registration, the device management with the correspondingoperations (see 2.4.4), and the information reporting with notifications. Some featurespresent in the LwM2M standard are not supported yet by Leshan, like the QueueMode, so that is the reason why it needs to be implemented for this project.

For the correct operation of the Queue Mode, there are three main features thatshould be supported by the Leshan server code, and therefore need to be implemented.Table 4.1 presents these features.

37

38 CHAPTER 4. QUEUE MODE IMPLEMENTATION AT THE SERVER SIDE

Table 4.1: Necessary features to support the Queue Mode at the server side.

Feature name DescriptionUpdate message detection Detect when a new update message arrives from the client,

which means that it is awake and can receive requests.Client awake time expiration Consider that the client is sleeping when its awake time

has expired after the last sent request. For the sleepingstate, the client does not send any message, so it is theserver that needs to handle this internally.

Request queuing Put in a queue the requests that are generated when theclient is sleeping, and send them when the client is awakeagain.

Two different implementations of the Queue Mode were done in this thesis. For themain goal of the project, which is to perform the comparison between Queue Modeand TSCH, a full implementation is done inside the Leshan core, which contains theactual queue for storing the requests, apart from the other necessary features. Afterproving the good performance, this code was proposed as a pull request inside theLeshan’s GitHub repository [8] as an addition to the thesis work, which resulted in areduced implementation with more basic functionality, as Section 4.2 explains.

4.1 Complete implementation of the Queue Mode

The Leshan’s LwM2M core consists of a set of files that constitute the necessarylibraries for building the Leshan server. As an example, there are files to manage thesending and reception of packets, the registration of a client, and the security. In thischapter only the relevant parts that need to be changed are mentioned. Figure 4.1shows the architecture of the Leshan server code.

The server is implemented as a Java class called LeshanServer that wraps all thelogic and contains all the necessary elements, which are objects from other implementedclasses. These elements are:

• A request sender that uses Californium to send CoAP requests.

• A list of registration objects. Each client that is registered in the server isidentified by an object from the class called Registration. This object containsthe relevant information of the registered client, like the IPv6 address, theendpoint name, the lifetime and the binding mode.

• Registration listeners that are notified every time a new registration, de-registration or update message from a client arrives. This is an API that thedeveloper can use in order to perform specific actions when these messagesarrive, by just implementing the methods registered(), updated() andunregistered(). But it is not responsibility of the developer to manage theregistration interfacer of LwM2M. The server core itself is in charge of addinga new Registration object to the list when a registration message arrives,

4.1. Complete implementation of the Queue Mode 39

Figure 4.1: Architecture of the Leshan server code. Only the interesting objects for the QueueMode implementation are shown.

updating the parameters when an update message arrives or removing theRegistration object from the list when a de-registration message is received.So this API is useful to perform specific actions.

• Other elements that are not relevant for the Queue Mode implementation, forexample to manage the resource observations or the security.

In order to implement the Queue Mode, some of this classes are modified, and somenew ones are added. This is explained in the following sections.

4.1.1 Listener for registration and update messages

The registration listeners that the Leshan code provides can be used to implementthe update message detection feature (see Table 4.1). These registration listeners arenotified when a client registers, updates it registration, and deregisters. Therefore,for implementing this feature, a registration listener is included in the Leshan Server,which is called LwM2mClientStateListener. Every time a registration message or anupdate message arrives, the listener checks if the client uses the queue mode, and inthat case it sets the state of the client to awake and sends all the requests that arestored in the queue. It also starts a timer to manage the client awake time, but thisis explained in more detail later in this section.

4.1.2 LwM2mQueue class for managing the Queue Mode of each client

In order to achieve the other two features (Table 4.1), which are client awake timeexpiration and request queuing, and also to manage the Queue Mode of each client in


an independent way, the approach taken in this thesis is to create a new Java classcalled LwM2mQueue to include all elements of the Queue Mode that each registeredclient needs. Every time that a new client registers specifying the Queue Mode as itsbinding mode, one object from this class is created and added to a list that the servermaintains, linked to the Registration object of the same client. The endpoint nameis used as the linker, so both the Registration object and the LwM2mQueue objectcontains the same endpoint name. With this implementation, the server can controleach device in a separate way. The LwM2mQueue class contains the following elements:

• The state of the client, which is defined as an enumeration type with two differentvalues: AWAKE and SLEEPING.

• A timer to manage the client awake time, in order to achieve the client awaketime expiration feature. As it is explained in Chapter 3, the client stays awakefor a specific time before going to sleep in order to receive new requests from theserver. This time is controlled by an internal timer, and it can be dynamicallyadapted (Section 3.1.3) or set with a fixed value. So the idea is that the serverhas also a timer that controls the client awake time, that is started on everyupdate message, and restarted on every request sent. When this timers expires,the state of the client is set to SLEEPING, and from that moment the generatedrequests need to be placed in a the queue. For setting the time, a read requestto the client’s queue object (Section 3.3) is sent.

• A queue to store requests when the client is sleeping. This is used forimplementing the request queuing feature. This queue has a policy in orderto optimise the number of requests. Before adding a new request, the server firstchecks if a request of the same type and to the same resource is already present.In that case, it removes the old request and adds the new one.

4.1.3 Request Sender with Queue Mode operation

The last step in the server implementation is to achieve the request queuing necessaryfeature (Table 4.1). This means placing in a queue all the requests that are generatedwhen the client is sleeping, and send them when the client is awake again. In order todo this, the implementation of a new request sender class is added. This class is calledLwM2mQueueModeRequestSender, and it is based on the code of the request senderthat Leshan already includes, which is called CaliforniumLwM2mRequestSender. Thisclass has several methods for sending requests that require two main parameters:a Registration object identifying the destination client, and the request which isrepresented as a LwM2mRequest object. The sending can be done in a synchronousway, which means that the request sender waits after sending a request until it getsa response or until a timeout expires, or in an asynchronous way where the requestsender adds a callback function that is executed when a response or a timeout occurs,so it does not block the execution.

For sending messages, the CaliforniumLwM2mRequestSender uses the Californiumlibraries that implement the CoAP protocol. Two main functionalities are used from

4.1. Complete implementation of the Queue Mode 41

this module: the send() function that is used to send a CoAP packet, and thepossibility to add a message observer to a request. This message observer containscallback functions that are executed by the Californium core when some events happen,such as when a response is received, a request is retransmitted or the timeout hasexpired. So the CaliforniumLwM2mRequestSender operation can be divided in threesteps:

1. Create a message observer and add it to the request. If the request is sentin a synchronous way, this observer has the SyncRequestObserver type, whichcontains a method that waits until a response is received or the timeout expires.On the other hand, if the request is sent in an asynchronous way, this observer hasthe AsyncRequestObserver type and offers the possibility of including responseand timeout callbacks.

2. Send the request using the Californium Core.

3. If the request is sent in a synchronous way, call the method waitForResponse()that blocks until the response is received or the timeout expires.

Figure 4.2 shows a flowchart of the implemented request sender. This new requestsender class implemented (LwM2mQueueModeRequestSender) checks first if the clientuses Queue Mode. If it does not use it, then the request is sent in the same way asin the CaliforniumRequestSender. Otherwise, if the client uses Queue Mode thesender checks its state by getting the LwM2mQueue object from the registration objectthat represents this client. If the client is awake, it simply sends the request as inthe CaliforniumRequestSender and restarts the client awake timer. But if the clientis sleeping, the request is put in the queue inside the LwM2mQueue object, which isimplemented as a Java list. For synchronous requests, a new message observer iscreated. This observer blocks the timer that controls the timeout of the request whileit is located in the queue, because otherwise it will execute the timeout callback andwarn the user about the impossibility of sending the request, when the request has notbeen sent yet. In order to do this, a flag is set to true and the timeout timer is blockedusing a lock. When the request is sent out of the queue, this flag is set to false andthen the timeout timer continues normally.

Figure 4.2: Flowchart of the Queue Mode request sender.

Finally, to complete the request queuing feature, when theLwM2mClientStateListener detects an update message and sets the client’s state


to awake, it also iterates over the queue and sends all the queued requests to theclient, using this request sender.

4.1.4 Complete Queue Mode Operation in the LwM2M Core

In the previous subsections all the new elements added in the Leshan core have beenpresented, and now it is shown how this elements are connected to each other inorder to offer a full Queue Mode operation. Figure 4.3 illustrates this interconnection,showing the new classes added to the core. The LeshanServer object contains objectsfrom these classes together with the ones shown in Figure 4.1, which are not includedhere for simplicity.

Figure 4.3: Complete operation of the Queue Mode inside the Leshan server. Only the objectsadded to the Leshan core for this purpose are shown.

The client operating with Queue Mode sends an update message every time it wakesup. This is detected by the LwM2mClientStateListener, which is in charge of settingthe state of the corresponding client to AWAKE, start the client awake timer, and sendthe queued requests. In order to perform all those actions, the LwM2mQueue class offersseveral methods. First the method setAwake() is called for setting the state of theclient to AWAKE, which informs the request sender that the client can receive requests.This method itself calls another method of this class called sendQueuedRequests()that sends the requests that have been put in the queue when the client was sleeping.This method iterates over the Java list that contains the requests, and send them usingthe QueueModeRequestSender.

The startClientTimer() is also executed by the LwM2mClientStateListenerwhen the update message is detected. Each LwM2mQueue object contains a timer thatcontrols the client awake time, so that the server can know when the client is sleepingagain, since it does not send any message for this purpose. For setting the expiration

4.2. Reduced implementation with Presence Listeners 43

time of this timer, a read request to the queue object present in the client is sent.This is done every time the client wakes up because it may change from one iterationto the next one, if the client uses the dynamic adaptation explained in Section 3.1.3.If the client has a fixed awake time, then this read request can be done only once atthe beginning. When this timer expires, the method setSleeping() present in theLwM2mQueue class is executed to set that state in the client. This timer is restarted bythe QueueModeRequestSender every time it sends a new request, because the clientstays awake for this time since the last received request, and not from the updatemessage.

It is also important to remark that when the client sends the registration message atthe beginning, the server checks if the Queue Mode is used as binding mode, and in thatcase it creates a new LwM2mQueue object linked to the corresponding Registrationobject that identifies the client, and adds it to the list present in the LeshanServerobject where all these objects are stored. Then, it does the same actions explainedbefore when an update message arrives in order to set the state as awake and startthe timer, but it does not send any queued request because there can not be requestsfor a device before it is registered.

4.2 Reduced implementation with Presence Listeners

Once the implementation of the Queue Mode inside the Leshan server was testedand proved that it was working properly, a pull request was made to the Leshan’sGitHub repository [8], as an addition to the thesis work. The goal was to open thisimplementation to the community so that the Queue Mode can be used in their ownopen source projects. As a result of a discussion with the main contributors, it wasdecided to create a first version of the implementation slightly different and moresimple that the one done for the thesis, and then add more features from what hasbeen implemented in this project.

This implementation is based on having the possibility to create a new type oflisteners that are notified when the client state changes to awake or sleeping, in orderto perform some actions that the future developer decides. This is useful to havemore flexibility to run different types of applications on top of the core that want toperform several actions depending on the state of the client. In this implementation, noactual queues where the requests can be stored are present, only this listeners feature,so the responsibility of not sending requests when the client is sleeping relies on theapplication. This is the reason why this implementation is called reduced.

In order to do this, only a few modifications to the previous implementation arerequired. First of all was creating an interface called PresenceListener which has twomethods: onAwake() and onSleeping(). These methods are called when the state ofthe client changes, and future developers can just implement this interface and includeinside those methods the code that they want to execute.

The second main change was to create the class PresenceService that containsall the necessary logic for managing the Queue Mode. This class has a list with all the


PresenceListeners that have been created, and another list with all the LwM2mQueueobjects of the registered clients. This class has been renamed PresenceStatus, andcontains the same elements except the request queue.

The methods for managing the timer have also been moved from PresenceStatusto the new class PresenceService for a better implementation. Therefore, in this pullrequest the PresenceStatus object contains a timer that the PresenceService getswhenever it wants to start, restart or stop it.

Figure 4.4 shows the operation of this Queue Mode code, which is similarto the previous one that was implemented for the thesis project. TheLwM2mClientStateListener (now renamed PresenceStateListener) is notifiedwhen a new update message arrives. Then, it calls the method setAwake fromthe PresenceService class. This method extracts the PresenceStatus object thatcorresponds to the client, set its state to AWAKE, gets the timer and starts it. Thenit iterates over the list of listeners and notifies them by executing their onAwake()method. When the timer expires, the state is changed back to sleeping, and thelisteners are again notified, calling the onSleeping() method. In this implementation,the QueueModeRequestSender operation is the same as before, and the timer is alsorestarted on every request sent.

Figure 4.4: Queue Mode operation inside the Leshan server for the pull request. Only thenecessary objects added to the Leshan core are shown.

Chapter 5

Evaluation

The last step of the thesis, and the one that achieves the scientific goal, is the evaluationof the Queue Mode comparing it against another low power strategy. This strategy isthe TSCH MAC protocol (Section 2.5). Therefore, the comparison is made betweentwo power saving strategies at different levels of the network stack. The Queue Modeis performed at the application level, where LwM2M decides when to sleep and whento wake up (turn on and off the radio), and TSCH is done at the MAC layer as a wayof radio duty cycling. The purposes of the evaluation are:

• Determine which protocol has a better performance according to different metricsand depending on the IoT scenario. This scenario is defined based on differentaspects like the frequency in which the server requires data from the nodes, orthe immediacy in which this data is required. As a result of this evaluation, thethesis could be used as a guideline for future developers to decide which protocolto use.

• Test the performance of the Queue Mode itself and see if there are some issuesin the implementation that were not noticed before.

5.1 Hardware platform

The hardware platform Zolertia Firefly [34] is used for the evaluation experiments ofthe thesis. Figure 5.1 shows this platform and its components. It is an electronicboard designed specifically for IoT applications, and Contiki-NG supports it with allthe necessary drivers. The core of this board is the Zoul module [35], developed alsoby Zolertia. It is based on the Texas Instruments CC2538 [36] which is a System-on-Chip (SoC) that includes an ARM Cortex-M3 microprocessor with 512 KB of flashmemory and 32 Kb RAM memory, and a transceiver for 2.4GHz IEEE 802.15.4. TheZoul module adds also the transceiver CC1200 [37] to enable the communication inthe Industrial, Scientific and Medical (ISM) bands of 868, 915, 920 and 950MHz, inorder to support all possible channels present in IEEE 802.15.4. Therefore, this boardis designed to build networks using this protocol as the physical layer. Apart from this

45

46 CHAPTER 5. EVALUATION

core module, the Firefly platform includes also a on-board printed antenna for sub-1GHz and a ceramic antenna for 2.4GHz. It also has a reset and a general purposebutton, an RGB LED and a USB interface for programming and debugging.

Figure 5.1: The Zolertia Firefly hardware platform.

SICS has developed an IoT testbed that contains 25 Firefly platforms distributedin an office environment, connected to a central server. These platforms can beprogrammed independently to test IoT applications with a larger number of nodes.The testbed is used to run experiments in which the LwM2M client is located insidea network with different number of hops between the server and itself, where othernodes act as routers in the network.

5.2 Evaluation Setup

To perform the evaluation, it is necessary to build a network that connects the LwM2Mserver with the LwM2M client. Three different elements are part of this network: theLwM2M server implemented using the Eclipse Leshan code (Chapter 4), a borderrouter, and the LwM2M client implemented that runs in Contiki-NG (Chapter 3).The border router acts as a gateway between the WSN nodes and the Internet, inwhich the server is located. Contiki-NG provides a software that implements a borderrouter, which acts as the RPL coordinator of the network, and tunnels the internettraffic through its USB interface to the host it is connected, which in this case is acomputer running Linux. The border router gives a public IPv6 key to every nodein the network, with a fixed prefix. In this thesis, for simplicity the Leshan serverruns also in the host computer and not in the cloud inside the Internet. Runningit in the cloud would just add more transmission delay to the packets, but for thepurpose of this project it is considered enough to run it locally in the host. So in allthe experiments, the Leshan server runs in the host computer and the border router isconnected to it through USB, tunnelling the Internet traffic. Both of them are placedon an office desk.

The LwM2M client is another node present in the IoT network in which the borderrouter is the coordinator. For the evaluation, we have run experiments with different

5.3. Evaluation Metrics and Scenarios 47

numbers of hops between this border router and the client. For the experiments withone hop, Figure 5.2 (a) shows the setup. The client is placed in the same desk andconnected to the same host computer to collect the relevant data through the USBinterface. But for scenarios with more hops, the setup is the one illustrated in 5.2 (b).In this case the SICS testbed is used, where one node is programmed to be the LwM2Mclient, and the rest act simply as routers in charge of forwarding packets inside thenetwork until they reach the border router. In order to achieve the desired number ofhops, only some of the nodes are programmed and the rest are turned off. We haverun scenarios with 2 and 3 hops.

(a) Evaluation setup with one hop.

(b) Evaluation setup with several hops.

Figure 5.2: Setups used to build the IoT networks for the experiments in the evaluation part.

5.3 Evaluation Metrics and Scenarios

The evaluation part of this project is mainly focused on low power consumption,because that is the purpose of the Queue Mode. But other metrics also need to betaken into account in the comparison, in order to make an comprehensive evaluationof the performance of each protocol. It is necessary to compare both protocols notonly in terms of energy efficiency, but also in relation to other aspects of the networkthat can be affected by the low power strategies. Table 5.1 shows the metrics thatare defined for the evaluation, based on the usual parameters that are used amongacademia in the evaluation of IoT protocols [24] [29] [38] .


Table 5.1: Metrics defined for the evaluation of the Queue Mode in comparison with TSCH.

Metric DescriptionEnergy consumption The total energy consumed by the client node.

Round Trip Time (RTT) The time since the server attempted to make a requestuntil the response to that request, sent by the client,arrives. Retransmissions due to packet losses are notconsidered inside this time.

Packet Reception Rate (PRR) Ratio between the number of packets that are receivedcorrectly by the client, and the total number of packetssent. If either the request or the response is not received,one packet is considered as lost.

Memory footprint The memory usage that the implementation of the eachprotocol adds to the whole OS.

Once the metrics are defined, experimental scenarios also need to be defined inorder to perform this part of the project. These scenarios determine the differentparameters used for each protocol, and which kind of communication is establishedbetween the server and the client. We decide to build two different types of scenariosto cover as many different situations as possible. Both scenarios are evaluated usingQueue Mode and TSCH. These scenarios are:

1. Synchronized requests scenario: In this scenario, the server sends fiverequests to different resources present in the client with a fixed period of time.For the Queue Mode, this period is synchronized with the client sleeping time,which means that when the client informs the server with an update messagethat it has woken up, the server sends the five requests and then waits until thenext update message from the client. In scenarios where the nodes use the TSCHprotocol, the server has a fixed period to send the five requests.

2. Randomized requests scenario: The server sends the five requests at arandom point inside the defined period. This means that on every periodiciteration, the server calculates a random time offset, and after that time it sendsthe five requests. The time offset is taken using a uniform distribution from 0 tothe period value. In the Queue Mode case, if the client is sleeping after this timeoffset, the server puts the requests in the queue and sends them when the clientis awake again. For scenarios running TSCH, the server just sends the requestsat the random time instant.

The scenarios are run with different configuration parameters of both protocols.For Queue Mode, three different sleep and awake times are used, giving nine possiblecombinations. The selected client awake times are: 1 second, 5 second and the dynamicadaptation enabled (Section 3.1.3). For this dynamic adaptation, a margin of 100% isselected, because the time between two consecutive requests in these scenarios is juston the order of tens of milliseconds and therefore it is safer to have a high percentagemargin. This margin gives enough time time for the server to send the desired requests,

5.3. Evaluation Metrics and Scenarios 49

and makes client awake time still appropriate for low power purposes. Section 5.5.1shows results that proof this fact. In a different network with larger time between toconsecutive requests, this margin should be reduced to achieve a good energy efficiency,otherwise the awake time would be too long. The selected sleep times are 10 seconds,60 seconds, and 5minutes. These are also the sending periods used by the server inthe scenarios running TSCH. With these three values, a large amount of use cases iscovered. Ten seconds simulates a very demanding scenario where the server requestscritical data very often. Sixty seconds is used as a middle point between a demandingscenario and a low demanding one, which is simulated with the 5minutes. This isa scenario where power saving is the main goal and where the data retrieved bythe nodes is not critical, so the server does not need it very often. Later in theevaluation, the notation QMode-<sleeptime>-<awaketime> is used to refer to thesedifferent configurations.

For the TSCH MAC protocol, three different schedules are tested:

• 6TiSCH minimal configuration [28]: all the nodes share the same time slot tocommunicate inside a slotframe. The length of the slotframe is 7, which thedefault one defined in Contiki-NG. This gives every node one TX/RX slot every70 ms, and a contention mechanism is used in order to reduce the collisions thatcan occur because all the nodes share the same time slot.

• Orchestra default configuration: every node has a slot for TSCH beacons in aslotframe with a length of 397 (one slot every 3970 ms), another slot for RPLmulticast traffic in a slotframe with a length of 31, and finally one unicast slotfor communicating with its parent and several to communicate with its children,both in a slotframe with a length of 17. The last slotframe is the one used for theCoAP packets, and its length determines the radio duty cycle that is interestingfor the comparison.

• Orchestra with a larger slotframe length: to save more energy, the length of theslotframe dedicated to CoAP traffic is increased to 71, in order to reduce theradio duty cycle. This means that each node will have one slot every 710ms forcommunicating with its parent or children inside the network.

There are also nine possible scenarios using TSCH, as each schedule is used withdifferent server periods for sending the requests, which are the same as the sleepingtimes with Queue Mode: 10 s, 60 s and 5min. The notations used to identify thesescenarios is TSCH-<sending period>-<schedule>, where schedule can be: minimal,Orchestra-17 or Orchestra-71.

Apart from these two main scenarios, we have run additional ones to see if thereare any remarkable differences. One of these is a scenario in which the server doesan observation request at the beginning to two different client resources, and then theclient sends notifications either in a periodic way, to evaluate periodic notifications,or at random instants, to evaluate a typical case in which a notification is sent everytime a resource changes, for example in a temperature monitoring scenario. Also wehave performed a scenario using Queue Mode with 93 seconds of client awake time as


recommended by the LwM2M specification, to show the consequences of using such along time.

5.4 Measurement of the Defined Metrics

In order to extract the desired metrics from the experiments, the implementation codeis changed to take the necessary measurements, save them to files, and then processthe data using Matlab scripts. For each metric, a different way of measuring is used:

• Energy consumption: in order to measure the energy consumed in the client, theEnergest module of Contiki-NG (Section 2.6) is used. With this software module,the times that the different hardware parts are turned on are measured andprinted through the USB interface to a file in the host, in a table format so thatthey can be imported to Matlab easily. The times extracted are CPU in activemode, CPU in low power mode, radio transmitting, and radio listening. Then,multiplying these values with the corresponding current that each hardware partrequires, the total energy consumption can be extracted. Table 5.2 shows thecurrent consumptions of these hardware components in the Firefly platform. TheZoul module has two different low power modes. In this project, as the purposeis to perform an evaluation, only the Low Power Mode 1 is used. But whendeveloping a real product, this low power mode is not enough to achieve largebattery lifetimes, because its current consumption is still too high. Therefore,for the calculation of the total energy consumption, the current consumption ofthe Low Power Mode 2 is used, as it is more realistic to use when calculating thedefined metric. A remarkable aspect of performing these measurements is thatthe node has a higher energy consumption that it would have in a real product,because it needs to print periodically the times through the USB interface, forwhich it is necessary to put the CPU in active mode even when the client is inthe sleeping state. The selected period to calculate and print these times is 500ms, which is enough to have a good sampling rate in order to extract results andplot graphs, but not affect too much in the total consumption. Even though, thishave consequences in the total energy consumption, as Section 5.7 where batterylifetimes are calculated shows. But as the purpose of the thesis is to perform anevaluation, this consequence is considered valid because it affects both protocolsin the same way.

Table 5.2: Current consumption values of the Zolertia Firefly hardware platform.

Component Current consumptionCPU Active Mode 20mACPU Low Power Mode 1 0.6mACPU Low Power Mode 2 1.3µARadio transmitting 24mA

Radio listening 20mA

5.5. Results 51

• Round Trip Time (RTT): this metric is measured by the server. When themethod for sending a request is called, it saves a timestamp. Then whenthe response to that request arrives, another timestamp is taken. Finally, thedifference between these two timestamps is calculated and saved in a file in atable format. Then this can be easily processed by the Matlab scripts, whichtake the mean and standard deviation of these values, without considering theretransmissions.

• Packet Reception Rate (PRR): this metric is also measured by the server. Everytime a CoAP retransmission occurs, the message observer attached to the requestincrements a variable that contains the number of retransmissions for thatconcrete request. Once the request is acknowledged or cancelled, the server savesto a file the total number of retransmissions made. Then with a Matlab script,the total number of packets lost and sent is determined, and with them the PRR.

• Memory footprint: for this metric the tool for measuring the size of a .elf filepresent in the ARM compiler is used. This tool can be called with the commandarm-none-eabi-size <filename>. With it, the total RAM and ROM memory usedby a concrete object module, for example the LwM2M engine, can be measured.Therefore, the memory footprint can be calculated with and without Queue Modeto see how much memory is used by it.

5.5 Results

This section explains the results that are derived from the execution of the differentscenarios independently, without comparing both protocols. It shows the obtainedmetrics and how they vary depending on the parameters chosen for the scenario, andalso the important aspects that are derived from the analysis of these metrics. Thefollowing sections show the actual comparison between Queue Mode and TSCH.

5.5.1 Queue Mode Scenarios

This sections shows the results obtained for the two types of scenarios made withQueue Mode enabled: synchronized and randomized. It explains the most importantresults from each scenario are explained and also highlights the differences betweenthem.

5.5.1.1 Synchronized requests scenario

In the synchronized scenarios, the LwM2M client using Queue Mode, has two differentstates that are repeated periodically. One state where the client is awake and the radiois turned on, and one state where the client is sleeping and the radio is turned off.Figure 5.3 shows the current consumed over time by the client node, in an scenariowith 60 s for sleeping time and 5 s for client awake time, as an example. For plottingthe current consumption of the device, it can not be directly sampled, only the time


that each component has been turned on in each 500ms slot is determined with theEnergest module. Therefore, the total current consumption is adapted to this period,which means that for every slot, the duty cycle of each component is calculated, andmultiplied by the current consumption. As an example, if the CPU has been activehalf of this time, it would contribute with 20mA during 250 ms, but in this graph itcontributes with 10mA during 500 ms, resulting in the same total consumption. Thisis useful to illustrate the current profile of the time in the node, even though it doesnot adjust completely to the real one. The vertical lines in the figure mark the instantswhen the client goes to sleep and wakes up. When the client is awake, a high baselineis produced due to the current consumed by the listening mode. Then, there are smallpeaks due to the transmission of packets, because this action needs additional current.In the sleeping state, only a small constant energy is consumed by the CPU in lowpower mode.

At the beginning of the scenario there is a high energy consumption state becausethe client is trying to connect to the Internet through the border router, with the radioalways on. Once it is connected, the periodic cycles start.

0 100 200 300 400 500 600

Time (s)

0

5

10

15

20

25

30

Cu

rre

nt

(mA

)

Current

Wake up instants

Sleep instants

Figure 5.3: Current consumed over time by the client node in a Queue Mode scenario withsleeping time 60 s and awake time 5 s.

If this energy is integrated, the total energy consumed by the node can becalculated. Figure 5.4 shows the accumulated energy consumed by the client over timein the same scenario as Figure 5.3. Here again the two states that the client has can beclearly seen. When the client is awake, the energy consumption curve has a high slope,with a value slightly higher than 21mA. This includes the current consumed by theradio in listening mode (20mA) plus the small contributions of the CPU and the radioin transmitting mode. This indicates that even when the client is awake, the CPU isnot all the time in active mode, because the OS itself puts it in low power mode if thereare no processes running, which for this scenario basically means there are no requests

5.5. Results 53

to process. Moreover, the duty cycles of each component calculated using the Energestmeasurements (Section 2.6) are 8.3% for listening mode, 0.03% for transmitting mode,1.47% for CPU in active mode, and 98.52% for low power mode. So this also showsthat the active mode duty cycle is much smaller than the radio in listening mode,and the transmitting mode is almost insignificant. When the client is in the sleepingstate, the slope of the energy curve is around 0.2mA. This is higher than just thecurrent consumption in low power mode because the CPU is also in active mode atsome time instants in this state, with a duty cycle of around 1%. These active instantsare used to calculate the consumption times with Energest and print them throughthe USB port, among other tasks. This adds an extra energy consumption that wouldnot exist in a final product would. The node does not need to do such tasks, so theactive CPU duty cycle is reduced, which also reduces significantly the total currentconsumption. But as the purpose of this thesis is to make just a comparison and theCPU extra consumption contributes in the same way to the energy consumption ofboth protocols, we consider the results valid for the evaluation.

0 100 200 300 400 500 600

Time (s)

0

200

400

600

800

1000

1200

1400

Energ

y(m

A*s

)

Total energy

Wake up instants

Sleep instants

Average energy consumption

Figure 5.4: Accumulated energy consumed over time by the client node in a Queue Modescenario with sleeping time 60 s and awake time 5 s.

In order to calculate the average energy consumption of the node, a linear regressionof the accumulated energy consumption can be taken. This linear regression needs todiscard the initial state where the client is connecting to the network. The linearregression can be used because the energy consumption follows a periodic cycle witha fixed tendency that continues in the future. With this linear regression, an accurateestimation of the total energy consumed in a future instant can be extracted. Of coursethis approximation would have a small error, positive or negative depending on thetime instant, as a result of the steps produced when the client is awake. But this erroris small enough to be considered acceptable, in the order of 50mAs in Figure 5.4, lessthan 0.02mAh. Finally, the slope of this linear regression gives an average current


consumption in the client node, which can be used to calculate the battery lifetime ifthe effective capacity of the battery is known, as Section 5.7 shows.

There are some cases where the update message is delayed, because the networkis more congested or simply because it is lost and the client needs to retransmit it.This effect causes the client to stay awake for a longer time waiting for the response ofthis packet, and the linear regression would not consider the energy consumed in thisphase. But the total energy consumed in those situations, as they do not occur toooften, does not have a high impact in the calculations of the battery lifetime, whichwould be slightly smaller than the calculated one.

Comparing all the scenarios run with Queue Mode, the most important differencebetween them is the radio duty cycles that are obtained, because they depend directlyon the sleeping time and the client awake time. Table 5.3 include these duty cycles forevery combination of the parameters used. The listening radio duty cycle, which thekey part of the energy consumption and the one that Queue Mode wants to reduce,is notably affected by these parameters. For 10 s of sleeping time and 5 s of awaketime, the duty cycle is 35.38% whereas for 5min and 1 s it is reduced to 0.49%. Alsothe results of this table show that the dynamic adaption is useful to reduce this dutycycle. In the 10 s scenario it can reduce the duty cycle from 35.38% to 5.84%, in the60 s from 8.3% to 1.03% and in the 5min from 1.8% to 0.22%. So this adaptation isappropriate to reduce the energy consumption, but it is necessary to check if othermetrics are affected negatively by it.

Table 5.3: Transmission and reception duty cycles (in %) in the Queue Mode scenarios.

1 Hop 2 Hops 3 HopsDuty RX Duty TX Duty RX Duty TX Duty RX Duty TX

5 s 35.38 0.13 34.9 0.11 35.77 0.121 s 12.9 0.17 13 0.18 12.89 0.1610 s

Dynamic 5.84 0.18 6.17 0.18 6.64 0.185 s 8.3 0.34 8.34 0.03 8.31 0.041 s 2.35 0.03 2.33 0.03 2.35 0.0460 s

Dynamic 1.03 0.03 0.99 0.04 0.86 0.045 s 1.8 0.01 1.8 0.01 1.78 0.011 s 0.49 0.01 0.51 0.01 0.5 0.015min

Dynamic 0.22 0.01 0.23 0.01 0.22 0.01

The transmission radio duty cycle always has a low value because this radio modeis only used when the client needs to send a response to the server. But Table 5.3shows that this value increases when the sleeping time is reduced, because the numberof packets per time transmitted by the server increases too. For 10 s the client sendsfive responses every ten seconds, but for 5min the five responses are only sent everyfive minutes, so the ratio is lower. Despite this fact, the difference between these dutycycles has a small impact in the total energy consumption.

If the number of hops is increased, the listening duty cycles are also slightlyincreased, because the RTT of the packets is higher, which means that the timebetween two consecutive requests is also higher. This increases the total time in which

5.5. Results 55

the client is awake, but again with a low impact in the total energy consumption.Figure 5.5 shows the energy consumption in a scenario with the same parameters (60and 5 seconds) but two hops, to illustrate that there are no considerable differenceswith the one hop scenario, shown in Figure 5.4. The initial phase where the clientconnects to the network is longer in this case due to the increment in the hop distance,but the difference in energy consumption is just around 0.08mAh, therefore it has nota high impact in the battery lifetime.

0 100 200 300 400 500 600 700 800

Time (s)

0

200

400

600

800

1000

1200

1400

1600

1800

2000

Energ

y(m

A*s

)

Total energy

Wake up instants

Sleep instants


Figure 5.5: Accumulated energy consumed over time by the client node in a Queue Modescenario with sleeping time 60 s and awake time 5 s and 2 hops.

With respect to the RTT metric, it is always on the order of tens of milliseconds,because when the request is done, the client is awake with the radio in listeningmode, so there are no high delays between the transmission and reception of packets.This metric is not affected by the sleeping or awake times. Figure 5.6 shows themean RTT calculated for a Queue Mode scenario with different number of hops.For this calculation, packet retransmissions are not taken into account, because thiswould notably increase the RTT due to more than one packet is needed betweenthe transmission of a request and the reception of its response. This would makethe metric confusing. The figure shows the mean RTT and the standard deviationof this calculation. It can be concluded that the mean RTT is only increased by afew milliseconds when more hops are placed between the server and the client. Thismeans that the actual transmission of packets takes less time compared to the timerequired to process the request or response in the client or in the server. The standarddeviation is on the order of a few milliseconds, but it increases when the number ofhops increases. This means that with three hops the RTT metric can have a value upto 90 ms, whereas with one hop it only reaches 74 ms. This fact indicates that eventhough the average value is almost equal, the number of hops affect the RTT metric.


71.54±3.3074.42±9.08

78.88±15.49

1 2 3

Number of hops

0

20

40

60

80

100

RT

T (

ms)

Figure 5.6: Mean round trip time in a Queue Mode scenario for different number of hops.

Finally, the obtained PRR is always above 96% in all the evaluated scenarios.There is not any correlation between the configuration of the scenario parametersand the PRR results. Also the dynamic adaptation does not affect this metric,so the selected margin is safe enough for the network conditions of these scenarios.Figure 5.7 illustrates the number of retransmissions that the server does until it getsthe acknowledgement response for each packet. It shows that for 48 packets there areno retransmissions, and for one packet there is one retransmission, so one packet outof 49 is lost.

48

10 0 0

0 1 2 3 4

Number of retransmissions

0

10

20

30

40

50

Num

ber

of packets

Figure 5.7: Number of retransmissions performed for each packet in a Queue Mode scenario.

5.5. Results 57

5.5.1.2 Randomized requests scenario

In the case of the randomized scenarios, there are no differences in the energyconsumption curve. The client node is still waking up and going to sleep in a periodicway, so the consumed current over time is the same as before. There are special caseswhere 10 requests are sent to the client, increasing the total amount of time that it isawake. This is produced when there are five packets in the queue, and the random timeoffset calculated by the server in the next iteration is smaller than the client awaketime. In this case, the new five requests plus the five that where queued are sent. Butthis only happens in a few cases and on average it does not affect the total energyconsumption. Figure 5.8 shows the energy consumption in a randomized scenario with60 s as sleeping time and 5 s as awake time. It can be seen that the energy consumptionis the same as in the synchronized scenario shown in Figure 5.4.

0 100 200 300 400 500 600 700 800 900

Time (s)

0

500

1000

1500

2000

2500

Energ

y(m

A*s

)

Total energy consumption

Total energy

Wake up instants

Sleep instants


Figure 5.8: Accumulated energy consumed over time by the client node in a Queue Moderandomized scenario with sleeping time 60 s and awake time 5 s.

The RTT metric is the one that is clearly affected by the randomized scenario.Considering the case in which the requests need to be put in the queue, the RTTcan have a value up to the sleeping time of the client, without considering anyretransmissions. Figure 5.9 shows the mean RTT for a scenario with 1 hop, 5 s asclient awake time, and sleeping times of 10 s and 60 s. The conclusion is that thesevalues increase a lot compared to the synchronized scenarios due to the queueing ofrequests.

The PRR metric is not affected by the randomness, because the transmission ofpackets is done in the same way as in the synchronized scenarios, it does not matterif the packets are previously put in the queue or not.

Finally, the conclusion made from the randomized scenarios is that they should not


3.70±3.22

34.37±17.08

10 60

Sleeping time (s)

0

10

20

30

40

50

60

RT

T (

s)

Figure 5.9: Mean Round Trip Time in a Queue Mode randomized scenario with sleepingtimes of 10 s and 60 s.

be used for applications in which the server requires data from the client at arbitrarytime instants and with a high immediacy. Queue Mode is useful if the server and theyclient are synchronized and the data is required at fixed and periodic time instants,when the client wakes up. Also it could be used if the data is not critical and theserver can wait for the requests until the client wakes up. The implementation donein this thesis allows the server to change the sleeping time of the client by a writerequest in the queue object (Section 3.3), so it can be changed at any point and doesnot have to be fixed all the time. This adds more reasons to use the Queue Mode in asynchronized scenario where the sleep time of the client and period in which the serverrequests data are the same, as this synchronized period can be changed.

5.5.2 TSCH Scenarios

After knowing the results obtained from the Queue Mode scenarios, this section showsthe results obtained with TSCH. Both types of scenarios are shown: synchronized andrandomized, and again the results and differences between them are explained.

5.5.2.1 Synchronized requests scenario

TSCH is a way of radio duty cycling based on dividing the time into slots that aregrouped in a slotframe and repeated periodically. This period is a lot smaller that theone used with Queue Mode, in the range of milliseconds to hundreds of milliseconds.This makes the energy consumption almost constant, with smaller peaks that areproduced when the client receives and transmits a packets. Figure 5.10 shows thecurrent consumed by a node using TSCH with the minimal schedule, and 60 s assending period for the server. The same procedure as in Section 5.5.1.1 is used todetermine the current consumption. It has a high consumption when the node is

5.5. Results 59

scanning for TSCH beacons in order to connect to the border router, and then oncethe schedule is established, the consumption is almost constant with small peaks whenpackets are received (vertical lines) and therefore responses are sent.

0 100 200 300 400 500 600 700

Time (s)

0

5

10

15

20

25

Cu

rre

nt

(mA

)

Current

Packet reception instants

Figure 5.10: Current consumed over time by the client node in a TSCH scenario with minimalschedule and a sending period of 60 s.

When communicating using the TSCH protocol, the schedule used plays animportant role in energy consumption because it determines the radio duty cycle. Thelistening duty cycle is reduced while the slotframe length uses in the communicationincreases. Therefore, the highest listening duty cycles are obtained using the minimalschedule (length 7), and the smallest using Orchestra with a length 71. Orchestra withits default configuration is at a middle point, with a length of 17. For the transmissionduty cycle, the schedule does not have an effect, but the sending period of the serverdoes. For smaller periods, the number of requests that need to be responded increases,and therefore the transmission duty cycle is increased.

Table 5.4 includes the transmission and listening radio duty cycles for all the testedscenarios, with the three schedules and with the three different sending periods for theserver. The table shows that for the minimal configuration the listening duty cyclesare around 3.5%, whereas with Orchestra-17 it is around 2.2% and with Orchestra-71 it is reduced to around 1.1%. So none of the configurations are able to reach aslow listening duty cycles as with Queue Mode (Table 5.3). For the transmission dutycycles, they are reduced while the sending period is increased. It can also be seen thatall the duty cycles are slightly augmented when the number of hops increases.

If the energy consumed is integrated, the accumulated energy over time can becalculated and the linear regression can be applied again to have an average currentconsumption. Figure 5.11 illustrates this energy consumption, from the same scenarioas Figure 5.10 (60 s and Orchestra-17). As the energy consumption over time is almost


Table 5.4: Transmission and reception duty cycles (in %) in the TSCH scenarios.

1 Hop 2 Hops 3 HopsDuty RX Duty TX Duty RX Duty TX Duty RX Duty TX

Minimal 3.58 0.24 3.63 0.32 3.94 0.32Orchestra 2.43 0.25 2.52 0.32 2.5 0.3310 s

Orchestra-71 1.36 0.24 1.42 0.32 1.47 0.39Minimal 3.49 0.06 3.52 0.08 3.59 0.09Orchestra 2.22 0.05 2.24 0.06 2.28 0.1160 s

Orchestra-71 1.18 0.05 1.2 0.08 1.21 0.09Minimal 3.47 0.02 3.49 0.03 3.45 0.04Orchestra 2.2 0.02 2.21 0.03 2.21 0.045min

Orchestra-71 1.15 0.02 1.15 0.04 1.15 0.03

constant, the accumulated energy curve is linear and does not contain steps as in theQueue Mode scenarios. Therefore, the linear regression used as an approximationis more accurate for these scenarios. There is again an initial state with a higherslope where the client is connecting to internet with the radio turned on all the time.The slope of the linear regressions that represents the average current consumptionis proportionally affected by the radio duty cycles, and therefore by the schedulesand periodicity used. Section 5.6 shows these values when comparing them with theaverage current consumption of the Queue Mode.

0 100 200 300 400 500 600 700

Time (s)

0

500

1000

1500

2000

2500

En

erg

y(m

A*s

)

Accumulated energy

Packet reception instants

Figure 5.11: Total energy consumed by the client node in a TSCH scenario with the minimalschedule and a sending period of 60 s.

The RTT metric is affected by both parameters: the slotframe length andthe number of hops. The slotframe length determines the distance between thetransmission and reception slots used to communicate between the parents and theirchildren in the network topology. This distance is the time that the packet waits inthe node from when it is received until it can be sent. So when the length increases,

5.5. Results 61

the distance also increases, causing the transmission time for the packet to becomehigher. This transmission time is also increased with the number of hops, again dueto the waiting time that the packets have in the additional nodes.

Figure 5.12 shows the mean RTT obtained for the three different schedules, eachone for 1 to 3 hops. It can be seen that the round trip times are increased by the twoparameters already mentioned. With TSCH there is clearly a trade off between theradio duty cycles and the RTT. To achieve low duty cycles, the schedule needs to belonger and therefore the RTT increases.

163.55±115.20

538.86±362.45

938.65±411.43

1 2 3

Number of hops

0

200

400

600

800

1000

1200

1400

RT

T (

ms)

(a) Minimal configuration.

332.10±42.85

607.83±236.09

930.54±364.12

1 2 3

Number of hops

0

200

400

600

800

1000

1200

1400

RT

T (

ms)

(b) Orchestra with slotframe length 17.

753.64±251.91

1426.86±24.55

2110.59±598.53

1 2 3

Number of hops

0

500

1000

1500

2000

2500

3000

RT

T (

ms)

(c) Orchestra with slotframe length 71.

Figure 5.12: Mean Round Trip Time in TSCH scenarios with different schedules and fordifferent numbers of hops.

One remarkable aspect is that the increments of the RTT are not as trivial toestimate as one could expect. As an example, incrementing the number of hops byone or doubling the slotframe length does not necessarily lead to a doubled RTT.This effect is provoked by the position in which the transmission and reception slotsare located inside the slotframe, which are determined using the receiver ID and thelength of the slotframe. If one hop is added but the position of the transmission slotof the new parent is closer to the reception slot of its child, then the delay in thishop is smaller. Also if the total length of the slotframe is increased but the calculatedpositions are closer, the increment in the RTT would not be as big as the incrementin the length.


Figure 5.12 (c) shows that for three hops scenarios, the mean RTT is higher than2 seconds. This means that the retransmission timeout of the server needs to beincreased, otherwise retransmissions happen when the packet is not actually lost.Therefore this parameter needs to be taken into account when developing an IoTapplication using TSCH with low radio duty cycles.

Finally, the PRR is also close to 100% in most of the cases. But it can be seen howthe PRR is reduced for longer slotframe lengths, which means that more packets needto be retransmitted. Figure 5.13 shows the number of retransmissions performed in ascenario with Orchestra-71 and 60 s as the sending period. In this case seven packetsare retransmitted.

41

7

0 0 0

0 1 2 3 4

Number of retransmissions

0

10

20

30

40

50

Nu

mb

er

of p

ackets

Figure 5.13: Number of retransmissions performed for each packet in a TSCH scenario withOrchestra-71.

5.5.2.2 Randomized requests scenario

In this case, there are no differences between the synchronized and the randomizedscenario. The performance is the same with respect to all the metrics. This is becauseTSCH schedules have a short period, so it does not matter at which instant the serversends the requests. On average, the energy consumption, RTT, and PRR are the same.This makes TSCH suitable to use in those scenarios where the server requests dataat random instants and it requires a high immediacy, where Queue Mode cannot beused.

5.6 Comparison between Queue Mode and TSCH

After seeing the results of each protocol independently, this section makes a comparisonbetween them with respect to the four metrics. As a result of this comparison,conclusions about which protocol is more suitable to use in each situation can be drawn.

5.6. Comparison between Queue Mode and TSCH 63

5.6.1 Energy Consumption

For the energy consumption metric, the average current consumption extracted usingthe slope of the linear regression can be used, to see which protocol requires morecurrent and therefore would have a lower battery lifetime. Four aspects contribute tothe average current consumption, the radio in listening and transmission mode, andthe CPU in active and low power mode. Usually the radio has a higher influence, butas a result of this evaluation, it is also proved that in some situations, even with ahigher radio duty cycle, if the active CPU duty cycle is much lower, the node consumesless energy.

5.6.1.1 Sending period 10 s

With a sending period of 10 seconds, the main conclusion is that the consumptionis always lower using the TSCH protocol, even when the dynamic adaptation of theclient awake time is enabled. For longer awake time, the listening duty cycles aretoo high (around 35% with 5 s and around 13% with 1 s), so this cannot be usedin practise. Figure 5.14 shows a comparison between the Queue Mode running withdynamic adaptation, which reaches around 5% of listening duty cycle, against thethree different TSCH schedules. The graphics illustrate the scenario with one hop,but there are no significant differences in energy consumption when the number ofhops is increased, as Section 5.5.1 explains. The slope, which is the mean currentconsumption of the node, is always lower in TSCH. The time needed to connect to thenetwork varies a lot when using TSCH, due to the random channel hopping that thenodes perform until they get a valid beacon from another node. The energy consumedin this phase is negligible compared to the total energy consumed in the node.

0 200 400 600 800

Time (s)

0

500

1000

1500

Energ

y(m

A*s

)

Dynamic vs Minimal configuration

Q-Mode slope =1.92

TSCH slope =1.43

Q Mode regression

TSCH Regression

Q Mode

TSCH

0 200 400 600 800

Time (s)

0

500

1000

1500

Energ

y(m

A*s

)

Dynamic vs Orchestra-17

Q-Mode slope =1.92

TSCH slope =1.20

0 200 400 600 800

Time (s)

0

500

1000

1500

Energ

y(m

A*s

)

Dynamic vs Orchestra-71

Q-Mode slope =1.92TSCH slope =0.99

Figure 5.14: Energy comparison for sending period 10 s between Queue Mode with dynamicadaptation and TSCH.

The conclusion drawn from these experiments is that for short sending periods,which represent a demanding scenario where the server requests data often, TSCH isa better choice with respect to energy efficiency.


5.6.1.2 Sending period 60 s

In this case, with Queue Mode and 5 s for the client awake time the listening duty cycleobtained is around 8%, which is again too high for low power consumption purposes.But when the client awake time is reduced to 1 s, the average current consumption withQueue Mode is lower than with TSCH. The listening duty cycle is reduced to 2.35%in this case. Figure 5.15 shows a comparison between this Queue Mode configuration,and the three different TSCH schedules. It shows that the average current is lower forthe Queue Mode in all the cases.

0 200 400 600 800

Time (s)

0

200

400

600

800

1000

En

erg

y(m

A*s

)

QueueMode-1s vs Minimal configuration

Q-Mode slope =0.78

TSCH slope =1.36

Q Mode regression

TSCH Regression

Q Mode

TSCH

0 200 400 600 800

Time (s)

0

100

200

300

400

500

600

700

800E

ne

rgy(m

A*s

)QueueMode-1s vs Orchestra-17

Q-Mode slope =0.78

TSCH slope =1.11

0 200 400 600 800

Time (s)

0

100

200

300

400

500

600

700

800

En

erg

y(m

A*s

)

QueueMode-1s vs Orchestra-71

Q-Mode slope =0.78

TSCH slope =0.90

Figure 5.15: Energy comparison for sending period 60 s between Queue Mode with 1 s clientawake time and TSCH.

It is important to remark that for Orchestra-71, the listening duty cycle is lowerthan with QueueMode-1s, but still the energy consumption is a bit higher. This isdue to the active CPU duty cycle, which is around 1% in Queue Mode and 3% inTSCH. This gives another important conclusion: in order to run the TSCH protocolmore CPU resources are needed, and therefore even with lower radio duty cycles, theconsumption can be above the Queue Mode.

If the dynamic adaptation is enabled, the slope is reduce to 0.5mA, which is evenmore efficient than the ones achieved with TSCH. Therefore, the experiments with60 s show that Queue Mode is better in terms of energy consumption, but the othermetrics need to be checked to conclude if it is a more suitable option than TSCH ornot (Sections 5.6.2 and 5.6.3).

5.6.1.3 Sending period 5min

Finally, as it is expected, with a sending period of 5minutes Queue Mode is even moreefficient than TSCH with any of the schedules. Even with a 5 s client awake time, thelistening duty cycle is 1.8%, which achieves an average current of 0.575mA. With thedynamic adaptation, this duty cycle is reduced to 0.22% and the current consumptionis around 0.26mA, which is the lowest one in all the experiments. Figure 5.16 showsthe comparison between the Queue Mode with dynamic adaptation and the threeTSCH schedules, to illustrate the improvement in energy efficiency that it produces.


0 500 1000 1500

Time (s)

0

500

1000

1500

2000

2500

3000

3500

Energ

y(m

A*s

)

QueueMode-1s vs Minimal configuration

Q-Mode slope =0.27

TSCH slope =1.38

Q Mode regression

TSCH Regression

Q Mode

TSCH

0 500 1000 1500

Time (s)

0

200

400

600

800

1000

1200

Energ

y(m

A*s

)


Q-Mode slope =0.27

TSCH slope =1.10

0 500 1000 1500

Time (s)

0

500

1000

1500

2000

Energ

y(m

A*s

)


Q-Mode slope =0.27

TSCH slope =0.88

Figure 5.16: Energy comparison for sending period 5min between Queue Mode with dynamicadaptation and TSCH.

Again the conclusion is that Queue Mode is more energy efficient in this situation,but the other metrics need to be checked to see if they are affected in a bad way.

5.6.2 Round Trip Time

Once the energy consumption is compared, the other metrics need to be checkedin order to see if the energy efficiency affects them. This section compares theRTT. As previous sections show, in scenarios with Queue Mode this metric is almostindependent from the scenario parameters. Changing the sleeping or awake times doesnot vary the RTT, and adding more hops slightly increases it, but not as much as itcould be expected, because most of the time is consumed in processing the packets.On the other hand, with TSCH the RTT is affected significantly by both the numberof hops and the schedule length.

Figure 5.17 shows a bar graph that compares the mean RTT obtained in all thescenarios, for different numbers of hops. The sending period is 10 s in all of them,because there is a larger number of packets sent in these scenarios, so the mean valueand the standard deviation get more accurate. The figure illustrates how for QueueMode the value is almost constant for each configuration, but for TSCH it increaseswith the slotframe length and the number of hops. This means that when using QueueMode, low radio cycles can be achieved without affecting the RTT, whereas for TSCHlowering these duty cycles translates in a significant increment in the RTT value.Section 5.6.1 shows that Queue Mode has a better energy efficiency for the sleepingtimes of 60 s and 5min, and now this section presents that Queue Mode has a betterperformance in relation to the RTT metric. These obtained results translate in thatfor these situations, Queue Mode is a more suitable option. TSCH should only be usedfor short sleeping times, like the 10 s used in the scenarios, where Queue Mode is notable to achieve a proper energy efficiency.


71.6 72.2 71.5

160.1

332.1

753.6

Q-M

ode-

5s

Q-M

ode-

1s

Q-M

ode-

dyna

mic

TSCH-m

inim

al-7

TSCH-o

rche

stra

-17

TSCH-o

rche

stra

-71

0

200

400

600

800

1000

1200

RT

T (

ms)

(a) 1 hop.

75.3 73.4 74.4

538.9607.8

1426.9

Q-M

ode-

5s

Q-M

ode-

1s

Q-M

ode-

dyna

mic

TSCH-m

inim

al-7

TSCH-o

rche

stra

-17

TSCH-o

rche

stra

-71

0

500

1000

1500

2000

2500

RT

T (

ms)

(b) 2 hops.

79.8 74.6 78.9

938.6 930.5

2110.6

Q-M

ode-

5s

Q-M

ode-

1s

Q-M

ode-

dyna

mic

TSCH-m

inim

al-7

TSCH-o

rche

stra

-17

TSCH-o

rche

stra

-71

0

500

1000

1500

2000

2500

3000

RT

T (

ms)

(c) 3 hops.

Figure 5.17: Round trip time comparison between all Queue Mode and TSCH scenarios, withdifferent numbers of hops.

5.6.3 Packet Reception Rate

Finally, the PRR metric is evaluated. Figure 5.18 shows a comparison between thePRR values obtained in all the scenarios, again in one bar graph for each number ofhops used. The sending period is again 10 s because more packets sent and thereforebetter results can be extracted. The value is always high, but these graphs show thatit is reduced in the TSCH scenarios while the slotframe length increases. This givesa similar conclusion than with the RTT metric, to achieve low radio duty cycles withTSCH, the PRR is adversely affected, whereas for Queue Mode it is independent. Thisconclusion gives another reason for the suitable use of Queue Mode.


100.0 99.7 100.0 98.7 96.1 96.8

Q-M

ode-

5s

Q-M

ode-

1s

Q-M

ode-

dyna

mic

TSCH-m

inim

al-7

TSCH-o

rche

stra

-17

TSCH-o

rche

stra

-71

0

20

40

60

80

100P

RR

(%

)

(a) 1 hop.

99.7 100.0 100.0 98.4 96.8

83.0

Q-M

ode-

5s

Q-M

ode-

1s

Q-M

ode-

dyna

mic

TSCH-m

inim

al-7

TSCH-o

rche

stra

-17

TSCH-o

rche

stra

-71

0

20

40

60

80

100

PR

R (

%)

(b) 2 hops.

100.0 99.7 100.095.2

91.6 93.5

Q-M

ode-

5s

Q-M

ode-

1s

Q-M

ode-

dyna

mic

TSCH-m

inim

al-7

TSCH-o

rche

stra

-17

TSCH-o

rche

stra

-71

0

20

40

60

80

100

PR

R (

%)

(c) 3 hops.

Figure 5.18: Packet Reception Rate comparison between all Queue Mode and TSCHscenarios, with different number of hops.

5.6.4 Memory footprint

This section evaluates the memory footprint that the implementation of the QueueMode adds to the LwM2M modules, and also compares the memory footprint for thewhole binary file that runs in the Firefly platform when using Queue Mode or TSCH.

Chapter 3 explains that the software modules that are modified in the LwM2Mimplementation inside Contiki-NG are the lwm2m-rd-client and the lwm2m-engine.Also, the lwm2m-notification-list is added to store notifications when the client wakesup (Section 3.2.1 and the lwm2m-q-object module is included to implement this objectthat manages the Queue Mode operation.

Table 5.5 shows the memory footprint of these modules, with Queue Mode enabledor disabled, with the goal of calculate how much memory usage does the Queue Modeimplementation add. For the lwm2m-rd-client, the table shows that the ROM memoryis increased by 364 bytes due to the code added to implement the state machine. Noadditional RAM is needed for this module. In the lwm2m-engine, the ROM is alsoincreased but with a lower value — 300 bytes — because less lines of code are added.


The engine with Queue Mode needs 8 bytes of additional RAM (uninitialized). Thelwm2m-notification-list, which is used inside the engine to store the notifications, adds739 bytes of ROM and 146 bytes of RAM, setting the length of the queue to storenotifications as 10. This length could be reduced in order to save RAM memory.Finally, the lwm2m-q-object adds 572 bytes of ROM and 219 bytes of RAM, but thismodules is not mandatory for the specification, it is only used for concrete purposes inthis thesis to have a better operation of the Queue Mode (Section 3.3). Therefore, thetotal ROM memory added by the implementation is 1985 bytes, and the total RAMmemory is 374 bytes.

Table 5.5: Memory footprint of the different LwM2M software modules with Queue Modeenabled and disabled.

text data bss dec

lwm2m-rd-client Q-Mode disabled 1806 1 566 2373Q-Mode enabled 2170 1 566 2737

lwm2m-engine Q-Mode disabled 4109 24 232 4365Q-Mode enabled 4409 24 241 4674

lwm2m-notification-list Q-Mode enabled 739 12 134 885lwm2m-q-object Q-Mode enabled 572 44 175 791

Now the memory footprints of the whole system with either Queue Mode or TSCHcan be compared to see which implementation has a larger one. Table 5.6 shows thesefootprints. The total amount of memory used is larger when running TSCH both withand without Orchestra than when running Queue Mode, with CSMA as MAC layer.TSCH minimal configuration requires 9934 bytes more of ROM memory and 2868bytes of RAM memory, while TSCH with Orchestra requires 10813 bytes of ROM and3004 bytes of RAM.

Table 5.6: Total system’s memory footprint when using Queue Mode or TSCH.

text data bss decQueue Mode 66082 2853 13696 82631TSCH-minimal 76016 1825 17592 95433TSCH-orchestra 76895 1909 17644 96448

The conclusion is that the Queue Mode implementation has a lower memoryfootprint than the TSCH one, which makes it more easy to fit in the memory-constrained devices.

5.7 Battery lifetime calculations

For the energy consumption metric, the average current consumed by the client nodehas been compared, which is calculated taking the slope of the linear regression appliedto the energy accumulated curve. But for IoT devices, a more clear metric is the actualbattery lifetime that the node would have when operating in fixed conditions. Thisgives a better picture of the energy efficiency, and can be used in the comparison ofthe two protocols.

5.7. Battery lifetime calculations 69

In order to do that, the value of the battery capacity is needed (in mAh). Withthis value and the average current consumption that is extracted from the experiments,an approximate lifetime can be calculated. When the Firefly platforms are used in areal deployment, they are usually powered using a couple of AA alkaline batteries,that give the necessary voltage. It is difficult to find a value for the battery capacity,because it depends on many factors, like the environmental conditions, the extractedcurrent, and the way the current is extracted (continuously or in steps). Also whilethe capacity decreases, the voltage also decreases and the battery becomes uselesseven though it still contains energy. Therefore, what is usually done in practice istake the nominal value of the capacity, and add a discharge safety as a percentage toconsider all these effects. A typical value for the capacity of alkaline AA batteries is2600mAh [39], and taking a discharge safety of 20%, this gives a capacity of 2000mAhto use in the calculations for this thesis. This would give just an approximation of theactual lifetime that the node would have in a real deployment, but is still useful in thecomparison between Queue Mode and TSCH.

It is important to consider that this battery lifetime would be much lower thatthe one achieved by the client node in a real deployment, due to the energy readingthat it needs to perform. In a real deployment, the node would be in low power modethe whole sleeping time, whereas in the experiments it needs to switch to active modeoften to calculate and print the times measured with Energest (Section 2.6). Theactive CPU duty cycles in sleeping mode in these cases are around 1%, which meansthat the current consumed is 0.2mA. This current is much higher than the 1.3µA ofthe LPM 2 (Table 5.2). Again, the purpose of this section is just to give a comparisonbetween both protocols with an approximate battery lifetime, so this is considered asa good enough approximation, because it affects both protocols in the same way.

Figure 5.19 shows a comparison between the lifetime achieved in the differentscenarios, for the three selected sending periods. This graphs show the results ofthe 1 hop configurations, but it has been showed in previous sections that the numberof hops does not affect significantly in the energy consumption.

From these graphs similar conclusions can be drawn. For a sending period of10 s, the Queue Mode is not suitable and TSCH has a clearly better efficiency. Theapproximate battery lifetime is low in all the cases because this scenario is verydemanding and the nodes cannot use low radio duty cycles. For a sending periodof 60 s, Queue Mode has a higher lifetime except when using the client awake time of5 seconds. The dynamic adaptation achieves a lifetime of almost half a year, whichcould be a suitable value considering the CPU behaviour that has been explained.Finally, for the sending period of 5min the dominance of the Queue Mode is morenotable, achieving a lifetime of 305 days with the dynamic adaptation enabled. It canbe seen along all the graphs that the lifetime achieved with TSCH with each schedule isalmost constant, and only slightly increased when lowering the sending period becausethere are less packets to receive and send.

In a real deployment, where the CPU is actually in low power mode all the sleepingtime of the node achieves, the lifetimes achieved would be much higher. With QueueMode, the total active CPU duty cycle in sleeping mode is around 1%, which translatesin a current consumption of 0.2mA for this active mode, plus 1.287µA from the low


10.9

25.4

43.5

58.7

69.5

84.6

Q-M

ode-

5s

Q-M

ode-

1s

Q-M

ode-

dyna

mic

TSCH-m

inim

al-7

TSCH-o

rche

stra

-17

TSCH-o

rche

stra

-71

0

20

40

60

80

100

Life

tim

e (

da

ys)

(a) Sending period 10 s.

42.4

108.1

165.2

61.1

75.3

92.9

Q-M

ode-

5s

Q-M

ode-

1s

Q-M

ode-

dyna

mic

TSCH-m

inim

al-7

TSCH-o

rche

stra

-17

TSCH-o

rche

stra

-71

0

50

100

150

200

Life

tim

e (

da

ys)

(b) Sending period 60 s.

144.9

254.6

694.4

61.6 76.194.2

Q-M

ode-

5s

Q-M

ode-

1s

Q-M

ode-

dyna

mic

TSCH-m

inim

al-7

TSCH-o

rche

stra

-17

TSCH-o

rche

stra

-71

0

200

400

600

Lifetim

e (

days)

(c) Sending period 5min.

Figure 5.19: Battery lifetime comparison between all Queue Mode and TSCH scenarios, fordifferent sending periods.

power mode. If the active CPU duty cycle when the client is sleeping is reduced tovalues closer to 0% (the CPU might also need to perform some actions in the sleepingstate), like 0.2%, the current consumption is reduced by 0.15mA. For the QueueMode scenario with 5min and dynamic adaptation, the current consumption wouldbe decreased from 0.27mA to 0.12mA, achieving a lifetime of almost 2 years.

The conclusion from this section is that the calculated lifetime are only to make acomparison between the two protocols from another point of view, that helps to drawthe final conclusions of the thesis. But this battery lifetimes in a real deploymentwould be much higher, so they should not be understood as final values.

5.8 Alternative scenarios

In this section some additional scenarios are evaluated, to gain more understandingabout the LwM2M’s performance. First, a monitoring scenario is tested, whichconstitutes a typical one used in IoT environments. In this scenario, the sensor nodestake data from the environment where they are placed, like a room or a mechanical

5.8. Alternative scenarios 71

structure, and send it to the server in a periodic way or when the values changesignificantly. Therefore, the server does not need to send any request. On the otherhand, an scenario with the default value for the client awake time recommended bythe OMA specification is used, to show the consequences that it has.

5.8.1 Monitoring scenario

This scenario is used as an example of a usual IoT application where the server doesnot make requests to the client to perform actions, but is only interested to retrievedata from it. One typical example are the applications for monitoring environmentalparameters, like the temperature of a room or the state of a bridge. In this case, theserver performs an observe request for the resources it is interested in, and then theclient send a notification periodically or when the value changes.

To simulate this kind of application, the Leshan server performs an observe requestto two different resources of the client using Queue Mode, and then the client sends anotification every time it wakes up. Figure 5.20 shows the accumulated energy curvethat is obtained when the sleeping time is set to 60 seconds and the dynamic adaptationis enabled. The listening duty cycle has a value of around 1%, but the transmissionduty cycle is reduced notably compared to the scenarios where five requests are made(from 0.33% to 0.03%). This translates to an average current consumption of 0.29mA,close to the cases with 5minutes of sleeping time in the previous scenarios. This wouldachieve a lifetime of 287 days, again considering the this is just an approximationbecause the CPU is active much more time than in a real deployment.

0 100 200 300 400 500 600

Time (s)

0

50

100

150

200

250

300

350

Energ

y(m

A*s

)

Figure 5.20: Accumulated energy consumed over time by the client node in a monitoringscenario using Queue Mode with dynamic adaptation and sleeping time 60 s.

If TSCH with Orchestra-17 is used in the same conditions, which means sending two


notifications every 60 seconds, the average current consumption is 1.1mA, almost thesame as in the previous scenario with 5 requests. Figure 5.21 shows the accumulatedenergy curve in this case. This only achieves a lifetime of 75.75 days.

0 100 200 300 400 500 600 700

Time (s)

0

200

400

600

800

1000

1200

1400

1600

1800

Energ

y(m

A*s

)

Accumulated energy


Figure 5.21: Accumulated energy consumed over time by the client node in a monitoringscenario using TSCH with Orchestra-17 and notification period 60 s.

For the RTT and PRR, the values are similar to the previous scenarios, becausethe transmission and reception conditions do not change. Then, the conclusion thatcan be derived is that in this kind of scenarios, Queue Mode is more energy efficientand a more suitable option than TSCH.

5.8.2 Scenario with default values recommended by OMA specification

This section aims to show the results that are obtained if the client awake timerecommended by the OMA LwM2M specification is used, which is 93 seconds inheritedfrom the CoAP protocol. The sleeping times of 10 s and 60 s does not make sense inthis case, because then the client would be longer time in the awake state than sleeping,so no energy would be saved.

Figure 5.22 shows the accumulated energy obtained using 5min as sleeping time.In this case, the listening duty cycle is 23.7%, which translates into an average currentconsumption of 5.056mA. This value is very high, and close to the previous scenarioswhere the sleeping time is 10 s, where it is shown that TSCH is more efficient. Itcan be seen that in the 93 s that the client is awake, the energy consumed is around2000 mAs (0.56mAh), which highlights that this awake time is too high for low powerconsumption purposes. With the calculated average current, the expected batterylifetime when using the same approximation as in Section 5.7 is only 16.5 days.

5.8. Alternative scenarios 73

0 200 400 600 800 1000 1200 1400 1600 1800 2000

Time (s)

0

2000

4000

6000

8000

10000

12000E

ne

rgy(m

A*s

)

Total energy

Wake up instants

Sleep instants


Figure 5.22: Accumulated energy consumed by the client node in a Queue Mode scenariowith default recommended client awake time (93 s) and a sleeping time of 5min.

Therefore, the sleeping time needs to be increased in order to achieve a low energyconsumption even with this client awake time. If it is set to 20 minutes, the achievedlistening duty cycle is 8.29%, which is close to the scenario with 60 s for sleeping and5 s for awake time. The average current consumption obtained is 1.8mA, which givesa battery lifetime of 46.29 days, which is still low.

These experiments show how the 93 seconds is a too high value for low powerconsumption in IoT devices. To achieve a radio duty cycle similar to the ones obtainedwith the dynamic adaptation (around 1%), the sleeping time needs to be over 2 hours,which is not suitable for most of the applications. But as this parameter is only arecommendation, it can be reduced a lot in order to achieve a high energy efficiency,without having a bad effect in the performance of the protocol, as it has been shownin this thesis.

Chapter 6

Conclusions and Future Work

The main goal of this Master’s thesis was to evaluate the performance of the LwM2Mapplication protocol using the low power strategies TSCH and Queue Mode. In orderto achieve this goal, the Queue Mode has been implemented at both sides of thecommunication, the server inside Eclipse Leshan and the client inside Contiki-NG. Asa result of the evaluation part of the thesis, the operation of both implementationswas tested, and we can conclude that it is correct and can be used in future projects.Moreover, a reduced version of the server software has been accepted and integratedas a pull request in the Leshan GitHub repository [8], showing the success of theimplementation part of this thesis.

For the evaluation, four different metrics have been used (energy consumption,round trip time, packet reception rate, and memory footprint) and different scenarioshave been tested, in order to compare both strategies. The conducted experimentsallow to draw the general conclusion that can be used as a guideline to select the mostsuitable low power strategy in each situation. TSCH is a better option in demandingscenarios where the server needs to communicate very often and therefore the sleepingtimes need to be low, which translates in a bad energy efficiency using Queue Mode.Also, in the cases where the server does not request data at fixed time instants andrequires this data with a high immediacy, Queue Mode is not suitable because theRTT can become too high, so TSCH should be used in these cases too. But in lessdemanding scenarios where the sleeping time can be higher and the server requires dataat fixed time instants, Queue Mode has been shown to be a better option in terms of allthe measured metrics. The energy consumption is lower and, in addition, the RTT, thenumber of lost packets, and the memory footprint are also lower. The battery lifetimesthat can be achieved with the Queue Mode are significantly higher. Therefore, QueueMode is a much more suitable option in this kind of scenarios. Finally for monitoringapplications where the client just needs to send data in form of notifications, QueueMode achieves an even better energy efficiency than TSCH because the awake timescan be reduced more.

For a correct operation, the Queue Mode requires that the client and the serverare synchronized, which means that the communication is done always when the clientis awake. The implementation done in this thesis favours this use case, because the

74

75

sleeping time does not need to be fixed since the starting point. The server can changethe sleeping time at any moment with a write request to the client’s Queue Object,for example if in concrete situations the server needs to communicate more often, itcan reduce the sleeping time of the client with a write request, and then set it back tothe higher one. This makes easy that the client and the server are synchronized andadds another reason to use Queue Mode in real IoT scenarios.

The main disadvantage of Queue Mode is that it can only be used in the leaf nodesof the network topology, and the router nodes need to keep the radio always on, usingCSMA, in order to route the packets. This means that these router devices cannotuse a battery as the power supply, because the energy would be drained quickly. Thisreduces the number of applications where Queue Mode can be used at the moment,and a way to reduce the radio duty cycle also in the router nodes using Queue Modeshould be investigated.

As future work, regarding the implementation of the Queue Mode, another wayto announce the client awake time could be done. In the current implementation theserver needs to do a read request every time, which is not really efficient. A possiblesolution could be to include this time as a parameter inside the update message that theclient sends to inform that it has woken up. In addition, a way of reducing the powerconsumption in the router nodes when using the Queue Mode could be investigated,as it was explained before, to increase the number of applications where Queue Modecan be used.

With respect to the evaluation, the performed experiments are done considering anetwork with a low congestion and interferences because only a few number of nodesare used, and with the server running locally. Experiments could be conducted in orderto see how the metrics are affected in such cases, for example when there are othernodes in the network sending different kinds of traffic, or when the server is running inthe cloud with a larger amount of clients registered. These experiments can be usefulfor a more comprehensive evaluation in other kind of scenarios.

References

[1] T. rep. IEC., “Internet of Things: The Wireless Sensor Networks,” 2014. Availableat http://www.iec.ch/whitepaper/internetofthings/. Visited 2017-10-31.

[2] Ericsson AB, “Internet of Things Forecast.” Web page. Available at https://www.ericsson.com/en/mobility-report/internet-of-things-forecast. Visited2017-10-26.

[3] R. T. Fielding and R. N. Taylor, Architectural styles and the design of network-based software architectures, vol. 7. University of California, Irvine Doctoraldissertation, 2000.

[4] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, andT. Berners-Lee, “Hypertext transfer protocol – http/1.1,” Internet RFC 2616,June 1999.

[5] “IEEE standard 802.15.4.” IEEE Computer Society, Oct. 2003.

[6] “Contiki-NG, the Next Generation Contiki.” Web page. Available at http://contiki-ng.org/. Visited 2018-01-27.

[7] Eclipse Foundation, “Leshan, OMA Lightweight M2M server and client in Java.”Web page. Available at https://www.eclipse.org/leshan/. Visited 2017-10-26.

[8] Eclipse Foundation, “Eclipse leshan github repository.” Available at: https://github.com/eclipse/leshan. Visited 2018-02-14, 2015.

[9] A. Dunkels, “The Contiki Operating System.” Web page. Available at http://www.contiki-os.org. Visited 2017-10-16.

[10] T. Watteyne, M. Palattella, and L. Grieco, “Using ieee 802.15.4e time-slottedchannel hopping (tsch) in the internet of things (iot): Problem statement,” RFC7554, Internet Engineering Task Force, May 2015.

[11] J. Postel, “Transmission control protocol,” RFC 793, Internet Engineering TaskForce, Sept. 1981.

[12] J. Postel, “User datagram protocol,” RFC 768, Internet Engineering Task Force,Aug. 1980.

[13] T. Winter (Ed.), P. Thubert (Ed.), and RPL Author Team, “Transmission ofIPv6 Packets over IEEE 802.15.4 Networks,” Internet proposed standard RFC4944, Sept. 2007.

76

http://www.iec.ch/whitepaper/internetofthings/

https://www.ericsson.com/en/mobility-report/internet-of-things-forecast

https://www.ericsson.com/en/mobility-report/internet-of-things-forecast

http://contiki-ng.org/

http://contiki-ng.org/

https://www.eclipse.org/leshan/

https://github.com/eclipse/leshan

https://github.com/eclipse/leshan

http://www.contiki-os.org

http://www.contiki-os.org

References 77

[14] T. F. Kernel, “Market Leading, De-facto Standard and Cross Platform RTOSkernel..” Web page. Available at https://www.freertos.org/. Visited 2017-01-27.

[15] RIOT, “The friendly Operating System for the Internet of Things..” Web page.Available at https://riot-os.org/. Visited 2017-01-27.

[16] Eclipse IoT Working Group, “The Three Software Stacks Required forIoT Architectures.” Web page. Available at https://iot.eclipse.org/white-papers/. Visited 2017-01-27.

[17] J. Postel, “Internet protocol,” RFC 791, Internet Engineering Task Force, Sept.1981.

[18] S. Deering and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,”RFC 2460, IETF, Dec. 1998.

[19] G. Mulligan, N. Kushalnagar, and G. Montenegro, “IPv6 over IEEE 802.15.4 BOF(6lowplan).” Web page. Visited 2017-10-17.

[20] “Cooja, network simulator for Contiki-NG.” Available at:https://github.com/contiki-ng/contiki-ng/wiki/Tutorial:-Running-Contiki%E2%80%90NG-in-Cooja. Visited 2018-02-14, 2017.

[21] A. Dunkels and O. Schmidt, “Protothreads – Lightweight Stackless Threads inC,” Tech. Rep. T2005:05, Swedish Institute of Computer Science.

[22] F. Wang, D. Li, and Y. Zhao, “Analysis of csma/ca in ieee 802.15.4,” IETCommunications, vol. 5, pp. 2187–2195, October 2011.

[23] E. Rescorla and N. Modadugu, “Datagram transport layer security version 1.2,”RFC 6347, Internet Engineering Task Force, Jan. 2012.

[24] M. Kovatsch, S. Duquennoy, and A. Dunkels, “A Low-Power CoAP for Contiki,” inProceedings of the Workshop on Internet of Things Technology and Architectures(IEEE IoTech 2011), (Valencia, Spain), Oct. 2011.

[25] Open Mobile Alliance, Lightweight Machine to Machine Technical Specification.Approved Version 1.0.1, July 2017.

[26] I. Alliance, “IPSO Objects: Defining Smart Objects.” Web page. Available athttps://www.ipso-alliance.org/. Visited 2017-10-17.

[27] A. Dunkels, “The ContikiMAC Radio Duty Cycling Protocol,” Tech. Rep.T2011:13, Swedish Institute of Computer Science, Dec. 2011.

[28] S. Duquennoy, A. Elsts, B. A. Nahas, and G. Oikonomou, “TSCH and 6TiSCH forContiki: Challenges, Design and Evaluation,” in Proceedings of the InternationalConference on Distributed Computing in Sensor Systems (IEEE DCOSS 2015),(Ottawa, Canada), June 2017.

https://www.freertos.org/

https://riot-os.org/

https://iot.eclipse.org/white-papers/

https://iot.eclipse.org/white-papers/

https://github.com/contiki-ng/contiki-ng/wiki/Tutorial:-Running-Contiki%E2%80%90NG-in-Cooja



https://www.ipso-alliance.org/

78 References

[29] S. Duquennoy, B. A. Nahas, O. Landsiedel, and T. Watteyne, “Orchestra: RobustMesh Networks Through Autonomously Scheduled TSCH,” in Proceedings of theInternational Conference on Embedded Networked Sensor Systems (ACM SenSys2015), (Seoul, South Korea), Nov. 2015.

[30] X. Jiang, P. Dutta, D. Culler, and I. Stoica, “Micro power meter forenergy monitoring of wireless sensor networks at scale,” in Proceedings ofthe International Conference on Information Processing in Sensor Networks(ACM/IEEE IPSN), (Cambridge, Massachusetts, USA), 2007.

[31] A. Dunkels, F. Österlind, N. Tsiftes, and Z. He, “Software-based on-line energyestimation for sensor nodes,” in Proceedings of the IEEE Workshop on EmbeddedNetworked Sensor Systems (IEEE Emnets), (Cork, Ireland), June 2007.

[32] SICS-IoT, “LwM2M client for contiki.” Available at: https://github.com/sics-iot/lwm2m-contiki. Visited 2018-02-14, 2016.

[33] Eclipse Foundation, “Californium, CoAP in Java.” Web page. Available athttps://www.eclipse.org/californium/. Visited 2018-01-16.

[34] Zolertia, “Firefly platform.” Available at: https://github.com/Zolertia/Resources/wiki/Firefly. Visited 2018-02-14.

[35] Zolertia, “The zoul module.” Available at: https://github.com/Zolertia/Resources/wiki/The-Zoul-module. Visited 2018-02-14.

[36] Texas Instruments, “Cc2538, a powerful system-on-chip for 2.4-ghz ieee 802.15.6-2006 and zigbee applications.” Web page. Available at http://www.ti.com/product/CC2538. Visited 2018-02-02.

[37] Texas Instruments, “Cc2538, low power, high performance rf transceiver.” Webpage. Available at http://www.ti.com/product/CC1200. Visited 2018-02-02.

[38] T. Pötsch, K. Kuladinithi, M. Becker, P. Trenkamp, and C. Goerg, “Performanceevaluation of coap using rpl and lpl in tinyos,” in 2012 5th InternationalConference on New Technologies, Mobility and Security (NTMS), pp. 1–5, May2012.

[39] Energizer, “E91 Alkaline AA Battery - Datasheet.” Available at http://www.batteryspace.com/prod-specs/1142_specification.pdf. Visited 2018-02-06.

https://github.com/sics-iot/lwm2m-contiki

https://github.com/sics-iot/lwm2m-contiki

https://www.eclipse.org/californium/

https://github.com/Zolertia/Resources/wiki/Firefly

https://github.com/Zolertia/Resources/wiki/Firefly

https://github.com/Zolertia/Resources/wiki/The-Zoul-module

https://github.com/Zolertia/Resources/wiki/The-Zoul-module

http://www.ti.com/product/CC2538



http://www.batteryspace.com/prod-specs/1142_specification.pdf

http://www.batteryspace.com/prod-specs/1142_specification.pdf

TRITA EECS-EX-2018:68

www.kth.se

energy-efficient communication with lightweight m2m in iot ...1306358/fulltext01.pdf · oma:s...

Documents