extensions to lwm2m for improved efficiency and ......boolean, opaque, time and objlnk (object...

Extensions to LwM2M for improved efficiency andinteroperability

Matthias Van Eeghem

Supervisors: Prof. dr. ir. Jeroen Hoebeke, Prof. dr. ir. Eli De Poorter Counsellors: Abdulkadir Karaağaç, Jen Rossey

Master's dissertation submitted in order to obtain the academic degree of Master of Science in Computer Science Engineering

Department of Information TechnologyChair: Prof. dr. ir. Bart DhoedtFaculty of Engineering and ArchitectureAcademic year 2017-2018

Preface

First of all, I would like to thank my supervisor, prof dr. ir. Jeroen Hoebeke for sparking my

interest in the Internet of Things because of his interesting elective course. I would also like to

thank him and both my counsellors, Abdulkadir Karaagac and Jen Rossey, for their continuous

support. They sat together with me every week and gave me feedback and helped me whenever

required. I could ask them anything and they were always quick to reply to emails.

I would also like to thank my parents for giving me the wonderful opportunity to study at

Ghent University for five years and supporting me throughout this entire process. I would also

like to thank my girlfriend, Lieselot, for her never ending support. And lastly I would like to

extend a thank you to my friends for the unforgettable memories, laughs and good times the

past five years.

Matthias Van Eeghem January 2018

4

Admission to loan

The author gives permission to make this master dissertation available for consultation and to

copy parts of this master dissertation for personal use. In the case of any other use, the copyright

terms have to be respected, in particular with regard to the obligation to state expressly the

source when quoting results from this master dissertation.

Matthias Van Eeghem January 2018

5

Extensions to LwM2M for improved

efficiency and interoperabilityby Matthias Van Eeghem

Supervisors: Prof. dr. ir. Eli De Poorter, prof. dr. ir. Jeroen Hoebeke

Counsellors: Abdulkadir Karaagac, Jen Rossey

Master’s dissertation submitted in order to obtain the academic degree of Master of Science

in Computer Science Engineering.

Department of Internet Based Communication Networks (IBCN)

Chair: Prof. dr. ir. Bart Dhoedt

Faculty of Engineering and Architecture

Academic year 2017-2018

Abstract

This dissertation has two goals: identifying inefficiencies within LwM2M and advancing the

interoperability with respect to the protocol. Three solutions are proposed. The first is the

Batch object. This is a new LwM2M object which allows the user to read from and write to

multiple resources at the time. The Batch object has two resources: the Batch configuration and

the Batch value resource. The Batch configuration resource allows its user to set the resources

they are interested in. The Batch value resource then allows for reading and writing of those

resources with a single request. The Reverse Batch is the second proposed enhancement: it is an

extension on top of the Batch object. It provides functionality to automatically send the data

in the Batch value resource to an external server periodically. The (Reverse) Batch object is

generally more efficient than the state of the art, except in some edge cases. This is because the

data is encoded slightly less efficient in the Batch object. Advancing the interoperability was

done by virtualizing legacy devices, this is the third proposed solution. It allows legacy devices

to interact with a LwM2M network while minimizing the coding that has to be done. The

architecture consists of three blocks: the Adaptor which communicates with the legacy protocol,

the Virtual Device Manager (VDM) which holds sensor-independent code and a slightly altered

version of a LwM2M client. Stress-tests were done by running multiple containers simultaneously

on a single machine. The RAM is the main limitation. A laptop with 8 GB of RAM holds about

220 instances, a Raspberry Pi holds about 20 instances.

6

1

Extensions to LwM2M for improved efficiency andinteroperability

by Matthias Van EeghemSupervisors: Prof. dr. ir. Eli De Poorter, prof. dr. ir. Jeroen Hoebeke

Counsellors: Abdulkadir Karaagac, Jen Rossey

Abstract—This dissertation attempts to do two things:increase the efficiency of the LwM2M IoT protocol on theone hand, and improve the interoperability on the other. Inorder to achieve the first goal, the Batch object is proposed.This is a new object that allows its user to read fromand write to multiple resources using a single request. Itsextension, the Reverse Batch object allows for periodicupdates of multiple resources without the user having tosend a request. Increasing the interoperability is done byvirtualizing legacy devices and allowing them to interactwith the LwM2M network.

Keywords—CoAP, LwM2M, Interoperability, Efficiency,Virtualization

I. INTRODUCTION

It is predicted that there will be 30 billion devices inthe Internet of Things by 2020 [1]. The Internet of Thingsis the collective name for the network of embeddeddevices that are all inter-connected. These devices areoften limited in processing capabilities and thereforerequire a special protocol stack to function properly.These protocols allow these devices to interact with therest of the Internet.

II. BACKGROUND

This section gives the reader some insight in theprotocols used in this dissertation.

A. CoAP

CoAP is a specialized protocol for constrained devices.It is an application layer protocol and is easily translatedto HTTP.

B. LwM2M

LwM2M or Lightweight Machine-To-Machine is builton top of CoAP. It is another protocol for constraineddevices and is used for device and applicationmanagement. There are LwM2M clients that connect toa LwM2M server. External M2M applications are thenable to interact with the clients through the server. Theconstrained devices act as the LwM2M clients.

The protocol defines an extensive object model.These devices have multiple objects, each of whichcan have a number of instances. Examples of suchobjects are Temperature, Position, Humidity, ... Theseinstances share a common set of resources but theycould have different values throughout instances. Anexample resource for the Position object could be theX-coordinate.

Every resource has a name, a resource ID and atype. The possible data types are: String, Integer, Float,Boolean, Opaque, Time and Objlnk (Object link). Theresources could also represent lists of these types.Uniform Resource Identifiers or URIs are used toreference resources: /object id/instance id/resource id.

LwM2M defines several encoding formats: TLV,JSON, Opaque and Plaintext. The LwM2M client mustsupport TLV only and may optionally support the otherthree formats. The LwM2M server has to support allfour. TLV stands for Type-Length-Value. It is an efficientformat that uses a compact binary representation.

III. CHALLENGES

This section is split up into two parts: the first dis-cusses some limitations of the LwM2M protocol, thesecond proposes some possible solutions.

A. Limitations

LwM2M allows reading an entire object instance usinga single request, but not a subset of those resources.Separate requests have to be sent to do that. The protocolalso allows for updating multiple resources within asingle object instance but does not allow for updatingmultiple resources across objects using a single request.

B. Possible solutions

This section dives into some of the possible solutionsto these problems and why they might not be ideal.

2

1) The FETCH/PATCH/iPATCH methods: Three newCoAP methods, FETCH, PATCH and iPATCH wereproposed by van der Stok et al. [2]. FETCH is usedas an alternative to GET, PATCH and iPATCH as analternative to PUT. They allow for partial reading andupdating object instances respectively. The iPATCHmethod is the idempotent version of the PATCH methodas the latter can cause side-effects.

This proposal increases flexibility but it does notsolve all of the challenges posed above. It is still notpossible to read from or write to multiple resourcesacross objects.

2) IPSO Smart Objects: IPSO defines the concept ofSmart Objects where multiple objects can be aggregatedinto one using the Web Linking Framework [3]. Thisconcept does not really apply here as the objects do notnecessarily relate to each other in a meaningful way.This method also does not allow for linking a subset ofresources.

3) Patent for using multiple URIs in M2Mcommunication: Wang et al. filed a patent thatproposes a method utilizing multiple URIs in M2Mcommunications [4]. The idea builds further on topof CoAP and not LwM2M, but it could be adaptedfor the latter protocol. Their proposal was that M2Mapplications could generate a special type of request: theMU or Multiple URIs type request. M2M applicationscould then get the values of multiple resources witha single response: the MV or Multiple Values typeresponse.

Additionally, a gateway or intermediate node couldaggregate multiple SU or Single URI type requests intoa MU type request. It could then also de-aggregate theMV type response into multiple Single Value (SV) typeresponses.

This approach requires the client, server and M2Mapplications to all support MV and MU type packets.These packets would also have the overhead ofadding the URIs for every resource of interest. TheLwM2M clients also cannot automatically send thestate of multiple resources without receiving a requestbeforehand. This approach is also not compliant withthe LwM2M standard.

IV. (REVERSE) BATCH

This section discusses the Batch and Reverse Batchobject, proposed by Karaagac et al. [5] [6]. These are

two solutions proposed in order to increase efficiencyusing the LwM2M protocol.

A. Batch

The Batch object is a new custom LwM2M object.It has two resources: the Batch configuration and theBatch value resource. The first of the two allows the userto set the resources they are interested in. The secondresource then allows the user to read from or write tothe resources referenced in the Batch configuration. TheBatch object uses a one-to-one mapping for the Batchvalue resource: the first value corresponds with the firstresource in the Batch configuration, the second valuewith the second resource, etc.

Both of these resources are defined as a list ofstrings. This is because the specification does notallow for mixed lists. Whatever the original type of theresource is, it is encoded as a string in the Batch object.

B. Reverse Batch

The Reverse Batch object is implemented as anextension on top of the Batch object. It allows its userto specify an external server to periodically send thevalue of the Batch value resource to. This is useful if anexternal application wants periodic updates to be sent:the application no longer has to make the requests itselfevery time.

The object does this by defining five new resources ontop of the existing two in the Batch object:

• Short Server ID: The Short Server ID (SSID) isthe resource defining which external server the up-date should be sent to, this integer maps internallyto an actual server and any required credentials.

• URI Path: The URI path specifies the exact pathon the server to write the update to.

• Periodicity: The periodicity defines how often theupdate should be sent (in seconds).

• Send confirmable message: If set to true, theLwM2M client sends a confirmable message, ifset to false, it sends a non-confirmable message.

• No response option: If this option is set, the serverwill not send a response to specific (or all) typesof messages.

V. VIRTUALIZATION

In this section, the second solution proposed by thedissertation is discussed: virtualizing legacy devices.

3

These devices are not limited to physical constraineddevices, but could also include APIs, external databases,etc. When these devices are virtualized, it allows themto interact with a LwM2M network without actuallysupporting the protocol themselves.

The proposed solution is shown in Figure 1.

Fig. 1. Overview of the architecture of the proposed solution.

The solution attempts to minimize the work that hasto be done to integrate a new device into the existingnetwork. It consists of three blocks of code:

• Adaptor: The Adaptor is the only piece of codethat should be changed. This block communicateswith the device through its legacy protocol.

• Virtual Device Manager: The Virtual DeviceManager or VDM is the central block in the setup.It receives updates from the Adaptor and passesthem on to the LwM2M client, Anjay. It alsoobserves changes in Anjay and passes them backto the Adaptor.

• Anjay: Anjay is a C implementation of a LwM2Mclient. This is the core of the solution.

These three blocks are put inside a Docker image andrun as a singular container. Docker is run in bridgedmode, this means that Docker get its own networkstack. The host and the container have a separate IPaddress, any ports that are opened in the container haveto be exposed explicitly in order to be accessible. TheseDocker instances are not meant to run on the constraineddevices themselves, but on a separate server. This serverwould often run multiple instances simultaneously.

A. Implementation

The Adaptor and VDM are both implemented inPython, they communicate with each other through acustom JSON protocol. The Virtual Device Manager isthe entry point of the container. Both the Adaptor andthe Anjay instance are then started. The Adaptor has tocomplete a two-step registration process with the VirtualDevice Manager:

1) Create any object instances, if required.

2) Send the list of resources that are being virtualizedand their initial values.

The Virtual Device Manager has to be registered withAnjay as a server in order to be able to send CoAPpackets. It also has some extra privileges, allowing itto write to read-only resources, create object instances,etc. Anjay had to be changed slightly in order to allowfor these changes.

VI. EVALUATION

In this section, the evaluation of both the (Reverse)Batch object and virtualization of legacy devices arediscussed.

A. (Reverse) Batch

First, getting the values of an increasing number ofresources of a single object instance is evaluated. Usingsingle requests is compared with using the Batch object.The total number of bytes required for both approachesare shown in Figure 2.

Fig. 2. Number of bytes exchanged for reading increasing numberof resources for both the Batch object and using single requests. Thedata is encoded once using TLV, once using JSON.

It is obvious that the Batch object is much moreefficient for both encodings.

In environments where a low Maximum TransmissionUnit (MTU) is present, the overall bigger sizes of theBatch object responses are something to consider asblock transfer has to be used to send these packets. Thisis shown in Figure 3.

4

Fig. 3. Total latency for reading an increasing number of resourcesusing both the Batch object and single requests. The data is encodedusing TLV. An MTU of 135 was set, forcing block transfer.

In the figure, a LoRa network is used as an exampleof a network with a low MTU. It is a Low-Power Wide-Area-Network (LPWAN). The TLV encoding is veryefficient so the impact of having block transfer is notas visible in this case, it only becomes obvious when sixresources are requested. Figure 4 shows the experimentdone using the JSON encoding instead.

Fig. 4. Total latency for reading an increasing number of resourcesusing both the Batch object and single requests. The data is encodedusing JSON. An MTU of 135 was set, forcing block transfer.

In this case, using single requests is more efficientthan the Batch object when requesting two resources.The efficiency depends on the type and number ofresources requested and the MTU present in the network.

If the packets are secured by Datagram TransportLayer Security (DTLS), this adds a significant overhead,as shown in Figure 5.

Fig. 5. Number of byes exchanged for reading increasing numberof resources for both the Batch object and using single requests. Thisis done once using Pre-Shared-Key encryption and once by using noencryption. The results are shown for the TLV encoding.

It is obvious that the overall overhead for usingsecurity is larger if it has to be applied to every singlepacket whilst for the Batch object, this only has to beapplied to the request and response.

In networks with high packet loss, there is a tradeoff to be made: when a Batch object response packet islost, more information is lost but the odds of losing apacket when making separate requests is much higher,as shown in Figure 6.

Fig. 6. The probability that information is lost for varying lossprobability p.

VII. CONCLUSION AND FUTURE WORK

This conclusion is split up into two parts once again:the first part discusses the most important results forthe Batch and Reverse object. The second part discussessome results and future work for the virtualization oflegacy devices.

A. Batch and Reverse Batch

The biggest advantage of using the (Reverse) Batchobject over single requests is the decreased total number

5

of packets and bytes that have to be sent. Packets arelarger when using the Batch object however, so inenvironments with a low MTU or high packet loss thishas to be considered. In most cases, the Batch objectand its extension, the Reverse Batch object are moreefficient than the state of the art.

Only when updating resources within the sameobject, it is possible that the existing method is moreefficient, depending on the data types and number ofresources.

The area where there is the most room for improvementfor the Batch object is the encoding. Right now, allresources, regardless of their original data type, areencoded as a string. A possible extension is supportingall types of resources: lists or object links are notsupported in the current iteration.

Two possible extensions for the Reverse Batchobject are to let the user choose the encoding of the datathat is sent -only JSON is supported now- and allow theReverse Batch object to write to multiple servers.

B. Virtualization

The concept of virtualization allows a wide array ofdevices that previously could not interact with a LwM2Mnetwork to communicate with other LwM2M devices.It is implemented in such a way that very little codehas to be written to implement it for a new legacy device.

An idea for future work is to try to minimize theDocker overhead. A separate container is run for everylegacy device, this could be optimized by allowingthe VDM and Adaptor to support multiple Anjayconnections.

REFERENCES

[1] Amy Nordrum, “Popular Internet of Things Forecast of 50Billion Devices by 2020 Is Outdated.”

[2] P. van der Stok and C. Bormann and A. Sehgal, “PATCHand FETCH Methods for the Constrained Application Protocol(CoAP).”

[3] Jaime Jimenez and Michael Koster and Hannes Tschofenig,“IPSO Smart Objects.”

[4] Chonggang Wang and Dale N. Seed and Lijun Dong and GuangLu and Michael F. Starsinic and Nicholas J. Podias and QuangLy and William R. Flynn IV and Zongrui Ding and Paul L.Russel JR and Qing Li, “Method and apparatus forusing multipleuniversal resource identifiers in M2M communications.”

[5] Abdulkadir Karaagac and Floris Van Den Abeele and JeroenHoebeke, “Challenges for Semantic LwM2M Interoperability inComplex IoT systems..”

[6] Abdulkadir Karaagac and Floris Van Den Abeele and JeroenHoebeke, “Challenges for Semantic LwM2M Interoperability inComplex IoT systems..”

Contents

List of Figures 14

List of Tables 16

1 Introduction 1

2 Background 3

2.1 CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 LwM2M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.1 The object model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.2 Observe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.3 Data formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Challenges 8

3.1 Limitations of LwM2M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2 Possible solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2.1 The FETCH/PATCH/iPATCH methods . . . . . . . . . . . . . . . . . . . 9

3.2.2 IPSO Smart Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2.3 Patent for using multiple URIs in M2M communication . . . . . . . . . . 12

4 (Reverse) Batch 14

4.1 Batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1.1 Observe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2 Reverse Batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5 Virtualization 20

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.2 Proposed solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.3.1 Changes made to Anjay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.3.2 Alternative implementations . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.4 Example implementation: LoRa server . . . . . . . . . . . . . . . . . . . . . . . . 27

6 Evaluation 28

6.1 Batch and Reverse Batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.1.1 Real-world examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

12

Contents 13

6.1.1.1 Exposing GPS location . . . . . . . . . . . . . . . . . . . . . . . 28

6.1.1.2 Exposing temperature, humidity, GPS location and battery state 31

6.1.1.3 Using GET on an object instance vs. using GET on a Batchobject’s value resource containing the resources of that instance 33

6.1.2 Theoretical evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.2 Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7 Conclusion and Future Work 47

7.1 (Reverse) Batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

7.1.1 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

7.2 Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

7.2.1 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Bibliography 50

Appendix A API between the Adaptor and Virtual Device Manager 52

A.1 Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

A.1.1 Possible return values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

A.2 Delete an instance and references to its resources . . . . . . . . . . . . . . . . . . 55


A.3 Create an instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56


A.4 Update the resource list by sending new resources of interest . . . . . . . . . . . 56


A.5 Value updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57


List of Figures

2.1 The CoAP stack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Overview of the LwM2M network environment. . . . . . . . . . . . . . . . . . . . 4

2.3 The LwM2M object model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.4 The LwM2M Temperature object. . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1 IPSO Smart Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 An example flow taken from the patent. . . . . . . . . . . . . . . . . . . . . . . . 12

4.1 The two resources in the Batch object. . . . . . . . . . . . . . . . . . . . . . . . . 14

4.2 A sequence diagram showing how to interact with the Batch object. Resource5913 is the Batch configuration, resource 5914 is the Batch value. . . . . . . . . . 16

4.3 The resources in the Reverse Batch Object. . . . . . . . . . . . . . . . . . . . . . 18

4.4 An example of the flow of the Reverse Batch object. . . . . . . . . . . . . . . . . 19

5.1 The legacy device on the bottom right is not able to communicate with the restof the network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.2 Overview of the architecture of the proposed solution. . . . . . . . . . . . . . . . 21

6.1 The LwM2M Position object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.2 Position generator sequence diagram using the Batch object . . . . . . . . . . . . 30

6.3 Number of packets required for reading increasing number of resources for boththe Batch object and using single requests. . . . . . . . . . . . . . . . . . . . . . 34

6.4 Number of bytes exchanged for reading increasing number of resources for boththe Batch object and using single requests. The data is encoded once using TLV,once using JSON. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.5 Total latency for both Batch requests and issuing single requests for both spreadfactor 7, 8 and 9 (SF7, SF8 and SF9). . . . . . . . . . . . . . . . . . . . . . . . . 37

6.6 The number of packets required for both JSON and TLV encoding when blocktransfer is used. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.7 Total latency for reading an increasing number of resources using both the Batchobject and single requests. The data is encoded using TLV. An MTU of 135 wasset, forcing block transfer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.8 Total latency for reading an increasing number of resources using both the Batchobject and single requests. The data is encoded using JSON. An MTU of 135 wasset, forcing block transfer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

14

List of Figures 15

6.9 Number of byes exchanged for reading increasing number of resources for both theBatch object and using single requests. This is done once using Pre-Shared-Keyencryption and once by using no encryption. The results are shown for the TLVencoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.10 The overhead in bytes for reading an increased number of resources for both theBatch object and using single requests. . . . . . . . . . . . . . . . . . . . . . . . . 43

6.11 The probability that information is lost for varying loss probability p. . . . . . . 44

6.12 The CPU and RAM usage for increasing number of Docker instances runningsimultaneously. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.13 The time to complete GET requests for increasing number of Docker instancesrunning simultaneously. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

List of Tables

5.1 Overview of ports and which application uses them. . . . . . . . . . . . . . . . . 22

6.1 Results for the different ways of updating the position in a sensor 10 times. . . . 31

6.2 Results for getting resource values over multiple objects. . . . . . . . . . . . . . . 32

6.3 Results for using GET on a Position instance vs a Batch object containing thesame resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.4 What contributes packet sizes for both the TLV and JSON encoding. . . . . . . . 35

16

Chapter 1

Introduction

This dissertation focusses on protocols in the Internet of Things. The Internet of Things (IoT)

is the next big revolution of the Internet. It is the idea that small sensors, vehicles, fridges,

traffic lights, heart monitoring implants, cameras, ... are all inter-connected and able to interact

with the rest of the Internet. Whereas normally data is largely generated by humans, it is now

primarily generated by things.

These things are mostly embedded devices with limited processing capabilities and memory.

This also makes them cheap however and thus widely usable. Because of their limitations, pro-

tocols that are normally used for communication are not appropriate here. A new set of open

protocols was designed to be used by these devices while still allowing them to interact with the

rest of the Internet.

The Internet of Things is growing explosively, it is estimated that it will consist of about 30

billion devices by 2020 [1]. This generates a lot of new data that allows for a wide array of

possibilities. This makes the entire phenomena very exciting, new applications that nobody

thought of before will surely be developed because of it. An example of this is Antwerp or The

City of Things [2]. One part of Antwerp now is a smart zone, an area with a network of smart

sensors and wireless gateways. This allows for real-time monitoring of traffic, energy usage, etc.

It could be used to optimize services for citizens.

The improvements suggested within this thesis are split into two main parts. The first part

attempts to improve efficiency when using the Lightweight Machine-To-Machine (LwM2M) pro-

tocol. The proposed solution is split up into two separate but related sections: the Batch object

and its extension, the Reverse Batch object. The second part of the dissertation focuses on

1

Chapter 1: Introduction 2

improving the interoperability within the LwM2M protocol. This is done by virtualizing legacy

devices that are currently unable to operate within a LwM2M network.

The structure of the dissertation is as follows: Chapter 2 gives an introduction to some In-

ternet of Things protocols used. Chapter 3 poses some of the challenges currently faced when

using these protocols. Chapter 4 discusses the first two proposed solutions: the Batch object and

the Reverse Batch object. Chapter 5 focusses on the third proposed solution, the virtualization

of legacy devices. Chapter 6 consists of an evaluation of the three proposed solutions. Lastly,

Chapter 7 concludes the dissertation, discussing the most important results and proposing some

ideas for future work.

Chapter 2

Background

This chapter gives the reader some background into the technologies and protocols used in this

dissertation. It consists of two parts. The first part discusses the Constrained Application Pro-

tocol (CoAP). The second discusses the Lightweight Machine-To-Machine (LwM2M) protocol.

2.1 CoAP

Constrained Application Protocol (CoAP) is a specialized protocol for constrained devices. Con-

strained devices are devices that are limited in processing capabilities, memory and power supply.

It is designed to be easily translated to HTTP and it is HTTP-like in the sense that it has some

of the same methods such as GET, PUT, POST, ...

Like HTTP, CoAP is also an application layer protocol. Its protocol stack is shown in Fig-

ure 2.1.

3

Chapter 2: Background 4

Figure 2.1: The CoAP stack.

2.2 LwM2M

Lightweight Machine-to-Machine or LwM2M is another protocol for the Internet of Things. It

is mainly used for device and application management. It is frequently used on top of CoAP.

There are LwM2M clients and LwM2M servers, the clients are located on the constrained devices.

The clients connect to a server and external M2M applications then communicate with them

through the LwM2M server. This interaction is shown in Figure 2.2.

Figure 2.2: Overview of the LwM2M network environment.


2.2.1 The object model

LwM2M defines an extensive object model, an example is shown in Figure 2.3.

Figure 2.3: The LwM2M object model.

An LwM2M client has multiple objects, each with a unique identifier: the object ID. Some

objects are mandatory and some are optional. The current set of mandatory objects is given by

the following list:

1. LwM2M Security: Contains the security information about the connections to the

servers configured in the client.

2. LwM2M Server: Contains the non-confidential part of the information about the con-

nections to the servers.

3. Device: Holds some basic information about the device.

Each object can have zero, one or multiple instances. Each object defines whether or not multi-

ple instances are allowed. Every instance shares the same set of resources but the exact values

in these resources can differ from instance to instance.

An example object is shown below, in Figure 2.4.


Figure 2.4: The LwM2M Temperature object.

The Temperature object is defined as a multiple-instances object, this means that multiple in-

stances can be created. The resource ID (RID) is shown in the left-most column, this number

uniquely defines each resource.

These values are not picked randomly, for example, the ”Sensor Units” resource will have re-

source ID 5701 throughout all objects for which a ”Sensor Units” resource makes sense. For

example, Figure 6.1 in Chapter 6, displaying the Position object, also has this resource.

A resource can have a few different access types:

• Read: The resource is read-only.

• Write: The resource is write-only.

• Read/Write: The resource is both readable and writeable.

• Execute: The resource is executable, the resource with ID 5605 in the Temperature object

is such a resource.

The LwM2M specification only allows resources to have the following data types: String, Integer,

Float, Boolean, Opaque, Time and Objlnk (Object link) [3]. It also allows for homogeneous lists

of these types but it is not possible to mix types within a single list. A resource could hold a

list of strings, but not a list of integers and floats mixed together. The fifth column in Figure


2.4 defines whether or not a resource is a list or not.

Referencing a specific resource is done using the Uniform Resource Identifier (URI)

/object id/instance id/resource id. Referencing an object is done using /object id and /ob-

ject id/instance id is used to reference a specific object instance.

2.2.2 Observe

It is possible to observe resources in the LwM2M client. If a resource is observed and its value

changes, the client issues a notification with the new value to all of the observers as long as

it deems the observer interested. How long an observer remains interested is implementation-

dependent.

2.2.3 Data formats

LwM2M defines several data formats:

• TLV: TLV stands for Type-Length-Value, it can be used for reading from and writing

to entire object instances, singular resources and multiple-value resources. TLV uses a

compact binary representation. It consists of three parts: the type, the length and the

value.

The TLV encoding has very little overhead and is easy to parse by constrained devices.

The encoding can also hold more complex data by using nested TLV triples.

• JSON: JSON can also be used for reading from and writing to entire object instances,

singular resources and multiple-value resources.

• Opaque: Opaque is used for read and write operations on singular resources where the

value of the resource is an opaque sequence of binary octets.

• Plaintext: Plaintext can only be used for reading from and writing to singular resources.

The LwM2M server must support all data formats, the LwM2M client must support only the

TLV data format but it may choose to support the other formats. In this dissertation, all tests

and experiments were done using both the TLV and the JSON format. The TLV format was

chosen because it has to be supported by both the LwM2M client and server, and the JSON

format because it is human-readable and widely used.

Chapter 3

Challenges

This chapter discusses some challenges that currently exist within LwM2M. It consists of two

sections: the first section discusses the limitations of the protocol. The second proposes some

possible solutions to these problems.

3.1 Limitations of LwM2M

LwM2M has some limitations which are discussed in this section. The enumeration below shows

what is possible and what isn’t within the protocol with regards to reading from and writing to

resources.

1. Reading from resources: LwM2M allows for reading an entire object instance using

a single packet. This returns a format where the URI and value for every resource is

present. It is not possible to read only a subset of resources. Reading multiple resources

over different objects in a single request is not possible. Separate requests have to be sent

in order to read the values of multiple resources.

2. Writing to resources: LwM2M allows an object instance to be updated partially or

entirely using a single request. This means that it is possible to write to multiple resources

simultaneously as long as they belong to the same object instance. As is the case with

reading resources, it is not possible to write to multiple resources across object instances

using a single request.

These issues are addressed by the Batch object proposed in Chapter 4. Another limitation of

LwM2M is that it is not possible to get periodic updates of multiple resources (without having

8

Chapter 3: Challenges 9

to send requests) using a single packet. This is what the Reverse Batch object proposed in

Chapter 4 attempts to solve.

3.2 Possible solutions

This next section offers a few potential solutions and discusses why they might not be ideal.

3.2.1 The FETCH/PATCH/iPATCH methods

Three new CoAP methods, FETCH, PATCH and iPATCH were proposed by van der Stok et

al. [4]. These methods could be used to partially update or read objects.

FETCH would be used as an alternative to GET. It allows the user to specify the resources

they are interested in, by specifying them in the headers of the request. This solves the problem

of not being able to partially read an object instance.

The other two methods, PATCH and iPATCH are used to partially update an object. The

PUT method can only be used to overwrite a resource with completely new contents and cannot

be used for partial changes, but these methods can. The difference between the two is that

iPATCH is idempotent while PATCH isn’t. Idempotence is the idea that the side-effects of

n > 0 identical requests are the same as for a single request. The PATCH method may also cre-

ate entirely new resources if a URI that was present in the request did not exist within the object.

An example of the idempotent iPATCH is shown below. The original state of the JSON docu-

ment is given by:

1 {2 "x": 30,

3 "y": 20,

4 "some-array": ["Hello", "!"]

5 }


The request that is executed is shown below:

REQ: iPATCH CoAP://www.example.com/object

Content-Format: 52 (application/merge-patch+json)

{ "x":45}

RET: CoAP 2.04 Changed

The resulting state of the JSON document is given by:

1 {2 "x": 45,

3 "y": 20,


5 }

An example of the non-idempotent PATCH method is shown below. The original JSON docu-

ment is given by:

1 {2 "x": 30,

3 "y": 20,


5 }

The request that is executed is shown below:

REQ: PATCH CoAP://www.example.com/object

Content-Format: 51 (application/json-patch+json)

[

{ "op":"add","path":"some-array/1","value":"World"}

]

RET: CoAP 2.04 Changed

The final state of the JSON document is given by:


1 {2 "x": 30,

3 "y": 20,

4 "some-array": ["Hello", "World", "!"]

5 }

This proposal, whilst increasing flexibility, solves some issues but not all of them. It is still

not possible to read from or write to multiple resources across different objects. The proposed

methods also add the URIs for all resources that should be read or written to to the request.

This adds a level of overhead.

Another issue is that CoAP has no concept of object instances, so these methods would have to

be adapted a bit before they could be implemented into LwM2M. Would these methods apply

to an object or an object instance? If they apply to an object instance, what happens with the

creation of new resources by PATCH? Are they applied to all other instances as well?

3.2.2 IPSO Smart Objects

IPSO defines the concept of Smart Objects where multiple objects can be aggregated using the

Web Linking Framework [5]. An example is shown in Figure 3.1.

Figure 3.1: IPSO Smart Objects


In the example, an IPSO Thermostat object is constructed by aggregating an IPSO Temperature

object, an IPSO Setpoint object and an IPSO Actuation object. They are linked using the Input,

Setpoint and Output links. However, in the current use case, the objects aren’t necessarily

related to each other and this concept thus does not apply. This also does not allow for linking

only a subset of resources and isn’t really a flexible solution.

3.2.3 Patent for using multiple URIs in M2M communication

Wang et al. filed a patent that proposes a method utilizing multiple URIs in M2M commu-

nications [6]. Their idea builds on top of CoAP and not LwM2M. The idea is that an M2M

application could generate a Multiple URIs (MU) type request. This type of request encapsu-

lates multiple resources references (URIs) into a single request. This MU type request is then

received by the LwM2M client. This client could then generate a Multiple Value (MV) type

response.

Alternatively, an intermediate node or gateway could also aggregate multiple single URI (SU)

type requests into one MU-type request. A MV type response could also be sent back atomically

to the M2M application or de-aggregated back into single requests by a gateway, if they target

separate M2M applications. This is shown in Figure 3.2.

Figure 3.2: An example flow taken from the patent.

The M2M application issues three requests in the figure above: one for temperature, pressure,

and smoke. The M2M gateway translates this into a MU request (message 2151,2,3). This is

then passed on to device A.

This approach has a few downsides when combining it with LwM2M. First of all, this idea

was thought of with CoAP in mind and there is thus no concept of a LwM2M server in the

patent. This means that not only the M2M application and the LwM2M client would have to


support multiple URI type requests and responses, but the LwM2M server as well.

Additionally, this would break some of the compatibility with LwM2M: this idea is not compliant

with the specification. There is also the overhead of having to add the URI for every resource

to every request. It is also not possible for the M2M application to receive periodic updates of

multiple resources without having sending a MU type request itself.

Chapter 4

(Reverse) Batch

This chapter consists of two parts: the first part discusses the Batch object, the second discusses

its extension: the Reverse Batch object.

4.1 Batch

The Batch object is a new custom LwM2M object, it was proposed by Karaagac et al. [7] [8]. It

only holds two resources: the Batch configuration resource and the Batch value resource. This

is visualized in Figure 4.1.

Figure 4.1: The two resources in the Batch object.

The first resource allows the user to set the configuration of resources that they are interested

in. The second resource allows the user to read from or write to multiple resources at once.

Both of these resources are lists of strings and are both readable and writeable.

As discussed in Chapter 2, the LwM2M specification does not allow resource types to be mixed

lists. Let’s say the Batch configuration points to two resources with different types, e.g: a float

14

Chapter 4: (Reverse) Batch 15

and a string. Then it is not possible to send a CoAP packet containing [3.14, ”Hello World”]

as the specification does not allow this. Instead we must send: [”3.14”, ”Hello World”]. This is

why all data is encoded as a string in the Batch value resource.

This luckily does not cause any problems with knowing which type a value represents. It is

known that ”3.14” is a double being encoded as a string and not a string containing 3.14 be-

cause the type of every resource is fixed in the LwM2M Object and Resource Registry [9]. This

reference lists all possible LwM2M objects, their resources and their types.

The usage of the Batch object is best explained with a figure. An example flow is visualized in

Figure 4.2.


Figure 4.2: A sequence diagram showing how to interact with the Batch object. Resource5913 is the Batch configuration, resource 5914 is the Batch value.

In the example, the Batch configuration is first set to contain two resources: /x/y/z and /a/b/c.

The second step simply reads back what was just written. The resources are directly linked with

each other: the first string in the Batch value resource corresponds with the first URI in the

Batch configuration, the second string with the second URI, etc. In the example, the value 42

corresponds with resource /x/y/z, and ”test message” is the value of resource /a/b/c.


The third and fourth step are more interesting. In the third, the Batch value resource is read.

These are the values of the resources pointed to by the Batch configuration. The values are

collected into a list of strings and returned in a single request. The fourth step shows the ability

to change the values of multiple underlying resources at a time.

One thing to consider though, is that using the Batch object, updating multiple resources is

an atomic operation. Either all resources are updated or none are (if the packet is lost for

example). Using single requests, the data in the resources might be left in an invalid state.

4.1.1 Observe

The Batch object has some special code to make the observe behaviour work correctly. If a value

of a resource is changed through the Batch object, the Batch object makes sure to propagate

this change to all of the potential observers of this resource.

The reverse is done as well: if a resource is present in the Batch configuration and it is changed

externally (i.e. not through the Batch object), observers of the Batch object are notified of a

change as well.

4.2 Reverse Batch

The Reverse Batch object is implemented as an extension on top of the Batch object. It changes

nothing to the existing functionality of the Batch object. It allows the user of the Batch object

to specify an external server to periodically send updates to.

The update that is sent is the value of the Batch value resource (with resource ID 5914). It is

sent in the LwM2M JSON format. The extension adds a few new resources to the object, these

are shown in Figure 4.3.


Figure 4.3: The resources in the Reverse Batch Object.

The following five resources are added to the LwM2M object:

1. Short Server ID: The Short Server ID (SSID) is the resource defining which external

server the update should be sent to, it is defined as an integer. Every server that is used

internally in Anjay is registered in a Server object and in a Security object as well. Every

server has a unique identifier, this is the Short Server ID.

The external server that should receive the periodic updates should thus be registered

in the LwM2M client as well. This could be done via bootstrapping. Any credentials re-

quired to interact with the server are found in the Security object with the corresponding

SSID.

2. URI Path: The URI path specifies the exact path on the server to write the update to,

it is defined as a string.

3. Periodicity: The periodicity defines how often the update should be sent (in seconds), it

is defined as an integer.

4. Send confirmable message: The CoAP specification defines confirmable and non-

confirmable messages [10]. The first should be used if the sent message requires an ac-

knowledgement, the latter should be used if this is not the case. This resource lets the


user define which type of message should be sent, it is defined as a boolean. If set to true,

the LwM2M client sends a confirmable message, if set to false, it sends a non-confirmable

message.

5. No response option: According to the CoAP specification, every request should still

elicit a response. The No Response option was proposed by Bhattacharyya et al. [11]. If

this option is set, the server will not send a response to specific (or all) types of messages.

This resource is defined as a boolean as well, if set to true, a response will not be sent, if

set to false, the regular process applies.

The Reverse Batch Object works as shown in Figure 4.4.

Figure 4.4: An example of the flow of the Reverse Batch object.

Its operation is simple but effective: the user no longer has to send a request they want an

update every x seconds.

Chapter 5

Virtualization

5.1 Introduction

In this section, the third major solution as proposed by the thesis is discussed. Virtualization

refers to the practice of creating a virtual version of something instead of the actual version. In

the context of LwM2M, it refers to enabling a legacy device to communicate with a LwM2M

network. A legacy device is a device which does not support LwM2M.

Figure 5.1 visualizes the problem.

Figure 5.1: The legacy device on the bottom right is not able to communicate with the restof the network.

20

Chapter 5: Virtualization 21

The legacy device in the bottom right of the image is not able to communicate with the rest of

the network. The virtualization solution proposed attempts to fix this.

The legacy device as referred to is a very broad concept. It entails things like: a sensor support-

ing only a legacy protocol, a database, an external Application Programming Interface (API),

...

5.2 Proposed solution

The proposed solution tries to minimize the work that has to be done to implement new types

of legacy devices. This is done by splitting the code up into three parts:

1. Adaptor: The Adaptor is the only piece of code that interacts with the legacy protocol,

database or API. This is the only block that has to be changed in order to implement a new

device. The Adaptor sends updates from its source to the Virtual Device Manager (VDM).

It also receives new values from the VDM and forwards them back to the underlying device,

if necessary.

2. Virtual Device Manager: The Virtual Device Manager (VDM) acts as the intermediary

between the Adaptor and Anjay (the LwM2M client). It receives updates from the Adaptor

and forwards them to Anjay through CoAP. It also Observes every resource of interest in

Anjay and passes on updates to the Adaptor.

3. Anjay: Anjay is the core piece of this solution. It is a C implementation of a LwM2M

client. This is the block enabling the legacy device to communicate with the rest of the

LwM2M network.

The three parts are shown in Figure 5.2.

Figure 5.2: Overview of the architecture of the proposed solution.


As the figure implies, all of these parts are run inside a Docker image. Docker is software

providing an additional layer of abstraction in the form of containers. These containers run

independently within a single instance of Linux and Windows, without the overhead of having

to maintain multiple Virtual Machines (VMs). Docker makes it very easy to share executable

code without having to rely on certain packages or versions of software being installed.

Docker supports three networking modes:

1. None: This mode does not allow access to the external network or any other containers.

It also will not configure any IP for the container.

2. Host mode: This mode makes the container share the host’s network stack and all

interfaces from the host are available to the container. Any ports that are opened in the

container are thus automatically opened in the host as well and vice versa.

3. Bridge mode: This is the default networking mode, both the host and the Docker con-

tainer have a separate IP address. Any ports that are opened in this mode are not accessible

to the container’s host by default and have to be exposed explicitly.

In the proposed solution, the third mode is used. Since Anjay has to be accessible from the

outside (from the LwM2M server), its port has to be exposed.

These are the ports being used by the container:

Port Application that uses it

5690 Anjay

5692 Virtual Device Manager (JSON)

5693 Virtual Device Manager (CoAP)

5694 Adaptor

Table 5.1: Overview of ports and which application uses them.

Inside the Docker instance, these four ports are being opened. Only one of them is being exposed

to the outside world however, port 5690. The exposed port has to be mapped to a different local

port on the host for every new instance or conflicts will occur.

This is why the bridge mode is being used: running multiple instances of Docker simultane-

ously is made easy. The ports for instances of the Adaptor and Virtual Device Manager can

never cause conflicts even though they are the using the same ports throughout all instances.


5.3 Implementation

The Adaptor and the Virtual Device Manager are both implemented in Python, they commu-

nicate with each other through a custom JSON protocol. The Virtual Device Manager (VDM)

is the entry point of the Docker image. The VDM then starts listening on two ports, one for

JSON packets and the other for CoAP packets, the latter is implemented by building the VDM

on top of CoAPthon, a CoAP server [12].

In the next step, the Adaptor registers with the Virtual Device Manager and is able to re-

quest that Anjay creates some object instances. This is done by sending the following packet to

the VDM:

1 {2 "registration": {3 "objects": [

4 {5 "object-id": 3360,

6 "amount-of-instances": 2

7 },8 {9 "object-id": 3303,


11 }12 ]

13 }14 }

In the example, it is requested that two instances of the Position object (ID 3360) and one

instance of the Temperature object (ID 3303) are created.

In the meantime, Anjay launches and registers itself with the VDM. This is required because

Anjay only allows incoming CoAP packets from servers that are registered with it. The VDM

then sends CoAP POST requests to Anjay for every object instance that should be created.

Anjay creates one or more instances of every requested object and returns the newly created

instance IDs to the VDM, which then sends the following response to the Adaptor:



4 {5 "object-id": 3360,

6 "instances": [0, 1]

7 },8 {9 "object-id": 3303,

10 "instance-ids": [0]

11 }12 ]

13 }14 }

The two instances created for the Position object in this example are assigned instance IDs 0

and 1. The instance ID assigned for the Temperature object is assigned ID 0. The Adaptor then

sends the list of resources it wants to virtualize by sending the following packet:


1 {2 "registration": {3 "resources": [

4 {5 "uri": "/3303/0/5701",

6 "value": "Celcius",

7 "type": "string",

8 "read-only": true

9 },10 {11 "uri": "/3360/0/5702",

12 "value": 42.07,

13 "type": "float",

14 "read-only": false

15 }16 ]

17 }18 }

There are other packets for sending and receiving updates, creating new instances, deleting

instances, virtualizing new resources, etc. The full API is available in Appendix A.

5.3.1 Changes made to Anjay

Some changes had to be made to Anjay in order to make this system work properly. These

changes are listed below:

• Pre-build Anjay with every LwM2M object: The idea is that only the Adaptor

should be changed when a new legacy device is implemented. This means Anjay comes

pre-packaged with every possible LwM2M object for this set-up. The objects should not

be exposed if they are not enabled, however.

If an object allows for multiple instances, this is easy: the objects are only enabled if

an instance is created. If an object only allows for a single instance, Anjay creates the

instances by default, so this should be changed to prevent this from happening. This can

be done by implementing it as a multiple instances object but only allowing the creation

of a single instance.


• The is virtual device manager boolean: This is a new boolean that is added to the

server structure internally. This is set to true for the VDM, this gives it some extra

permissions such as write access to read only resources. This is required to give read only

resources initial values. It also allows the VDM to create object instances.

• The resource write internal function: Every object implemented in the current im-

plementation of Anjay has to implement a resource write function if any resource is write-

able. One of the changes in Anjay is that every object should now also implement a

resource write internal function. This method allows the VDM to write to read-only re-

sources if the boolean mentioned above is set to true.

• No longer return constants: A side effect of being now able to write to read-only

resources is that objects should not return constants in the resource read function so the

resource write internal function actually has an effect.

5.3.2 Alternative implementations

Felter et al. have looked into the overhead of Docker [13]. They found that Docker is nearly

identical to native performance and faster than Virtual Machines in every category. There are

two exceptions to this: the Docker’s NAT (Network Address Translation) and I/O-intensive

programs.

When using the Docker’s NAT (for e.g. port forwarding), a small hit in latency is expected.

I/O-intensive programs require some fine-tuning to be run efficiently. Seeing as the proposed

solution isn’t such a program, this is not a concern here.

An alternative solution would be to not run all of this inside a Docker instance. This means

that the ports being used for the Adaptor, VDM and Anjay should all be unique seeing as the

Adaptor and VDM only support a single instance of Anjay at the time. This is possible but

might not be worth it seeing as the impact of running this inside a Docker instance is minimal.

If every last bit of performance is required of the server that runs these instances, the VDM

could be rewritten to support multiple instances of the Adaptor and multiple Anjay instances

instead. If this is done, only the Anjay ports should be unique.

Another possibility is to run multiple instances of the Adaptor/VDM/Anjay within a single


Docker instance, but this then also requires either making sure ports don’t conflict with each

other or have the VDM support multiple connections.

5.4 Example implementation: LoRa server

A custom Adaptor was written to test how easily this is implemented for a real world exam-

ple. The goal for this test is to standardize the management of a Low-Power-Wide-Area-Network

(LPWAN) infrastructure, as proposed by Hoebeke et al. [14]. An example of a LPWAN is LoRa.

For the example, the open source LoRa server is used [15]. This LoRa server has a specific

JSON REST API that is unique. The idea is that using this abstraction layer of virtualization,

an adaptor could be written for every possible API or system. This would then allow network

management to be standardized through the use of LwM2M.

The following steps were taken to make this system work:

1. Create the necessary LwM2M objects in Anjay: Ordinarily, this step shouldn’t be

taken as only standardized LwM2M objects would normally be used. In this case however,

a custom LPWAN Gateway object was added to Anjay.

2. Add an XML file to the LwM2M server (Leshan): This is required so that the

server understands the structure of this new LPWAN Gateway object. This step is also

normally not required but it is now for the same reason mentioned above.

3. Write the custom Adaptor that interacts with the LoRa server API: This is

the actual implementation part. In the example, the /api/gateways and /api/gateways/-

mac address/stats API methods are both polled every few seconds for updates. If an

update occurs, this is sent to the VDM which notifies Anjay. If a value changes in Anjay,

the Adaptor is alerted and it calls an underlying method in the server API.

Chapter 6

Evaluation

This chapter consists of two parts. The first part focuses on the (Reverse) Batch object and

analysing on its efficiency within LwM2M. The second part focuses on evaluating the perfor-

mance impact of virtualizing legacy devices.

6.1 Batch and Reverse Batch

In this first section, the Batch object and its extension, the Reverse Batch object, are evaluated.

6.1.1 Real-world examples

Before the Batch object is evaluated theoretically, a few real-world examples are listed below.

These examples are implemented once using the new Batch or Reverse Batch object and once

using what is currently available in LwM2M. The results are then compared.

6.1.1.1 Exposing GPS location

In the first example, an external system calculates the position of a sensor. We’ll call this ex-

ternal system the position generator. The position generator is tasked with notifying the sensor

of its new position. The sensor has the position generator registered as a server, this allows the

position generator to directly send CoAP packets to the sensor instead of having to go through

the LwM2M server.

28

Chapter 6: Evaluation 29

The position is always sent as an (x, y, z) triple. New values are stored in the Position ob-

ject, which can be seen in Figure 6.1.

Figure 6.1: The LwM2M Position object.

The resources with IDs 5702, 5703 and 5704 are updated every time a new position triple is

received. When using the Batch object, the sequence laid out in Figure 6.2 is followed.


Figure 6.2: Position generator sequence diagram using the Batch object

First, the LwM2M client registers with the position generator. Then, a Position object instance


is created. The instance ID is picked by the LwM2M client. In step three, a new Batch object

instance is created and the configuration is immediately set to the corresponding resource IDs

in the Position object.

Two other alternatives are compared to the flow proposed. In the first, the new position is

sent over three separate packets, one for the x, one for the y and one for the z coordinate.

In the second alternative, the new position is sent over a single packet, not using the Batch

object. This is possible within LwM2M as long as all resources belong to the same object.

In each solution, the position is updated 10 times. The packets for creating the Position object

and creating the Batch object are included in the calculations. The impact of having to create

these instances in the first solution becomes smaller over time. The results can be found in Table

6.1.

Batch (1 req.) No Batch (3 req.) No Batch (1 req.)

Total bytes exchanged 2.065 4.203 1.673

Total bytes sent 1.403 2.522 1.072

Total bytes received 662 1.681 601

Total payload sent (in bytes) 899 1.220 610

Total payload received (in bytes) 158 379 139

Total number of packets exchanged 24 62 22

Table 6.1: Results for the different ways of updating the position in a sensor 10 times.

We can see that using the Batch object is a lot more efficient than updating the (x, y, z) coordi-

nates separately in three different requests. Not using the Batch object for updating resources

within a single object is the most efficient here.

There is a trade-off to be made here: when the Batch object is used, the references to the

resource IDs are not included in the request, as explained in Chapter 4. The (x, y, z) triple are

floats encoded as strings, while in the alternative, they are more efficiently encoded.

6.1.1.2 Exposing temperature, humidity, GPS location and battery state

In the next example, an external system wants to know the temperature, humidity, GPS location

and battery state of the sensor. The system requests the following resources every 15 minutes:


1. Temperature object: /3303/0/5700 (Temperature value)

2. Humidity object: /3304/0/5700 (Humidity value):

3. Position object: /3360/0/5702 (X coordinate), /3360/0/5703 (Y coordinate), /3360/0/5704

(Z coordinate)

4. Device object: /3/0/9 (Battery state)

Three different ways of doing this are evaluated:

• Six separate requests (one for every resource): The external system makes six requests to

the different resources.

• One single request using the Batch object: The external system asks for the Batch object’s

value every 15 minutes.

• One single update using the Reverse Batch object: The Reverse Batch automatically sends

updates every 15 minutes to the external system.

The results can be seen in Table 6.2. The results are calculated for 96 updates in total (96 * 15

minutes is one day). Only the JSON data format is evaluated here because the Reverse Batch

object only allows sending updates encoded in JSON in its current implementation.

Separate requests Batch Reverse Batch

Total bytes exchanged 95.904 30.259 23.658

Total bytes sent 39.168 6.774 173

Total bytes received 56.736 23.485 23.458

Total payload sent (in bytes) 14.976 2.700 131

Total payload received (in bytes) 32.544 19.411 19.411

Total number of packets exchanged 1.152 194 98

Table 6.2: Results for getting resource values over multiple objects.

The Batch object is more efficient than making six separate requests but the Reverse Batch

object is even more efficient in this case: the data is automatically sent every 15 minutes.


6.1.1.3 Using GET on an object instance vs. using GET on a Batch object’s value

resource containing the resources of that instance

In this final example, a GET on an object instance is compared with GETting a Batch object’s

value containing all the resources of that instance. The data that is returned is exactly the same:

a value for every resource within that object instance.

The Position object (as shown in Figure 6.1) is used once again. The data is retrieved twice:

once encoded as JSON and once encoded as TLV. The results can be seen in Table 6.3.

Encoded as JSON Encoded as TLV

GETing the Position instance (total bytes) 292 129

GETting the Batch object’s value resource (total bytes) 291 155

Table 6.3: Results for using GET on a Position instance vs a Batch object containing the sameresources.

GETting the Position instance is more efficient if it is TLV encoded, but in the case of JSON

the Batch object is more efficient. This is of course very dependent on the type and amount of

the resources used. If an object would only contain strings as resources, the Batch object would

be more efficient in both cases.

6.1.2 Theoretical evaluation

In the following subsection, a more theoretical approach is used to evaluate the (Reverse) Batch

object.

Evaluation of increasing number of resources

As a first step, the impact of the number of resources that are aggregated within a single Batch

object is evaluated. The Position object is used once again, it has seven resources in total. For

every number of resources, aggregating these in a Batch object is compared against requesting

them separately.

The amount of packets required for both methods is visualized in Figure 6.3.


Figure 6.3: Number of packets required for reading increasing number of resources for boththe Batch object and using single requests.

It is obvious that the Batch object only requires two packets for any number of resources: one

packet for requesting the value of the resources and one that returns the contents. For single

requests, it is a different story. For an increasing number of resources we want to know the value

of, the number of packets also increases linearly.

Figure 6.4 shows the total number of bytes exchanged for getting the values of increasing number

of resources. The data is encoded once using TLV, once using JSON.


Figure 6.4: Number of bytes exchanged for reading increasing number of resources for boththe Batch object and using single requests. The data is encoded once using TLV, once using

JSON.

Whilst the Batch object incurs larger packet sizes overall, not as many requests have to be made.

It is also obvious that the TLV encoding is much more efficient than its JSON counterpart in

this case.

Table 6.4 shows the contributions of each layer to the packet sizes. The data in the exam-

ple is 4 bytes long.

TLV JSON

Total Overhead Total Overhead

Data 4 bytes / 4 bytes /

Encoding 7 bytes 3 bytes 43 bytes 39 bytes

CoAP headers 23 bytes 16 bytes 59 bytes 16 bytes

UDP, IP, Ethernet 65 bytes 42 bytes 101 bytes 42 bytes

Table 6.4: What contributes packet sizes for both the TLV and JSON encoding.

LoRa

LoRa is an example of a Low-Power-Wide-Area-Network (LPWAN). LoRa uses spreading factors

(SF) to set the modulation rate. It defines factors from SF7 up to SF12. SF7 means the shortest

airtime, SF12 the longest. For SF10, SF11 and SF12, the maximum payload size can only be


a maximum of 51 bytes, whereas it can be 115 bytes for SF9 and up to 222 bytes for SF7 and SF8.

Using the previous example, the latency when transmitting over a LoRa network can now be

calculated. The latency is equal to:

latency = airtime + constant (6.1)

This constant includes things like the processing delay and the time from the gateway to the

cloud. For the calculations that follow, this constant is neglected and the airtime is equal to the

latency.

This latency is calculated as follows: for the Batch request, the airtime for the request and

response are simply added together. For the single requests, the airtime for each separate re-

quest and response are added together. So if three resources are requested for example, the

following formula applies for the latency of single requests:

latency = airtime(req1) + airtime(resp1) + airtime(req2) + airtime(resp2)+

airtime(req3) + airtime(resp3) (6.2)

The formula for the latency for the Batch request is given by:

latency = airtime(request) + airtime(response) (6.3)

The packet size is given by the following formula:

size = 13 bytes (LoRaWAN header) +1 byte (compressed IPv6 and UDP header) +

CoAP part (CoAP header + options + payload) (6.4)

Using SCHC (Static Context Header Compression), it is possible to compress the IPv6 and UDP

header down to a single byte.

The latency for an increasing number of resources is shown in Figure 6.5 where the resources are

encoded using TLV. They are only plotted using spread factor 7 and 8 (SF7 and SF8) because

some packets become too large for SF9, SF10, SF11 and SF12.


Figure 6.5: Total latency for both Batch requests and issuing single requests for both spreadfactor 7, 8 and 9 (SF7, SF8 and SF9).

It is obvious that the latency for a single Batch response is larger since its overall packet size is

larger as well but the total latency for retrieving the same information using single requests is

much higher.

Low MTU

In this section, block transfer is discussed. Block transfer has to be used if the network has

a low Maximum Transmission Unit (MTU). This number is the maximum packet size that is

allowed to be sent by the network. In the LoRa example, block transfer is used also if packet

sizes exceed the maximum packet size allowed for a given spread factor. The minimum MTU

in Anjay is 135 bytes. This is required in order to be able to send block responses. This means

using SF9, SF10, SF11 or SF12 is not possible, seeing as 135 bytes is more than their maximum.

Looking at the previous example, from a certain amount of resources in a Batch configura-

tion, block transfer will be used. This might impact the performance negatively, this behaviour

is investigated in this section. It is once again evaluated by calculating the total airtime in a

LoRa network.

If the MTU is set to its minimum allowed by Anjay (135 bytes), the block size is set to 64

bytes. As long as the payload fits inside a single block, calculating the airtime remains un-

changed. If this is not the case, block transfer is used and this changes things slightly.


The following flow is followed:

1. For every packet, find the CoAP payload size.

2. Calculate the number of packets required: n = ceil( size64 ).

3. If this is equal to 1, stop here and calculate the airtime as done in Formula 6.3.

4. If this is larger than 1:

(a) Calculate the airtime of n requests:

i. For the first request, the CoAP part (headers + payload) is 27 bytes long.

ii. For the n - 1 other requests, the CoAP part is given by: size = 27 bytes + 2

bytes (block option).

(b) Calculate the airtime of the n responses:

i. For the first n - 1 responses: The CoAP part is given by: size = 16 bytes (CoAP

header) + 2 bytes (block option) + 64 bytes (block size)

ii. For the last response: The CoAP part is given by: size = 16 bytes (CoAP header)

+ 2 bytes (Block option) + (size − (n − 1) ∗ 64) (the remainder of the original

payload).

5. Sum the air-times for all CoAP parts calculated in step 4. Use Formula 6.4 to calculate

the airtime.

The number of packets required for both the JSON and TLV encoding are plotted in Figure 6.6.


Figure 6.6: The number of packets required for both JSON and TLV encoding when blocktransfer is used.

Figure 6.3 shows the number of packets required to complete all of the requests without block

transfer. There, the line for the number of packets required for the Batch object is a constant

two packets. In the above figure, this is no longer the case. This is because the packet sizes

of the Batch responses sometimes exceed the set MTU (135 in this case) and block transfer is

required.

The line for single requests is still a constant because none of the packets for single requests

exceed the MTU. This now poses a trade-off: the single requests require more packets but from

a certain number of resources, block transfer will be used and the Batch response will also require

multiple packets.

Figure 6.7 shows the latency for reading an increasing number of resources for both Batch

requests and single requests. The data is encoded using TLV in the figure below, with block

transfer enabled.


Figure 6.7: Total latency for reading an increasing number of resources using both the Batchobject and single requests. The data is encoded using TLV. An MTU of 135 was set, forcing

block transfer.

The figure shows a non-constant line for the Batch objects for both SF7 and SF8. This happens

when six or more resources are aggregated into a single Batch object. At that point, the Batch

response becomes larger than the MTU. The Batch object is still more efficient overall, even

when using block transfer.

This is aggravated when using JSON to encode the data instead of TLV. As seen before, JSON

is a more inefficient encoding. This behaviour is shown in Figure 6.8.


Figure 6.8: Total latency for reading an increasing number of resources using both the Batchobject and single requests. The data is encoded using JSON. An MTU of 135 was set, forcing

block transfer.

It is obvious that the Batch object is no longer unequivocally more efficient in this case. For

two requested resources, it is more efficient to use single requests.

Observe

In this subsection, the impact of using the Observe mechanism is discussed. This mechanism

allows CoAP clients to observe resources on the server. The server notifies the CoAP client of

changes to a resource as long as it deems the client interested.

The Observe mechanism does not impact the Reverse Batch object as the object controls the

timing: the updates are sent automatically.

It does impact the Batch Object though. If any resource in a Batch configuration is updated,

Anjay notifies all observers of the Batch object. The packets containing the updated values are

larger since every resource in the Batch configuration, even those unchanged, are included.

The CoAP client can thus choose between observing multiple resources at a time or observ-

ing a Batch object instance containing those same resources. The packets from the Batch object

might contain some redundancy, but there is some overhead to observing multiple resources as

well. The CoAP client has to send quite a few more packets asking the server to let it observe


those resources and has to keep stating its interest in those resources by re-sending the Observe

requests.

This means that, depending on how many resources the CoAP client wants to observe and

how often the continued interest has to be shown, it could be more efficient to observe a Batch

object containing those same resources instead.

Security

Security is also something to take into account when choosing between the Batch object or send-

ing single requests. In this paragraph, the previous example of reading an increasing number of

resource is once again revisited.

A PSK (Pre-Shared-Key) is used for symmetric encryption. This is then compared by send-

ing the data unencrypted. The data is encoded using TLV first in both cases. The results are

shown in Figure 6.9.

Figure 6.9: Number of byes exchanged for reading increasing number of resources for both theBatch object and using single requests. This is done once using Pre-Shared-Key encryption and

once by using no encryption. The results are shown for the TLV encoding.

It is obvious that security adds a significant overhead. The figure also shows that using encryp-

tion adds a non-constant factor to the number of bytes exchanged for single requests. This can

be seen more clearly by plotting the overhead separately.


This is calculated by subtracting the number of bytes for not using encryption from the number

of bytes for using encryption:

overhead = bytes using security − bytes not using security (6.5)

This is shown in Figure 6.10.

Figure 6.10: The overhead in bytes for reading an increased number of resources for both theBatch object and using single requests.

The overhead for using PSK encryption grows linearly for getting an increasing number of re-

sources using separate requests while it stays constant using the Batch object.

Since the packets are larger overall for using security, this means MTU problems arise more

quickly and block transfer has to be considered again.

Packet loss

Something that also impacts the decision in using either the Batch object or single requests is

packet loss. Using the Batch object requires only a single response, while using single requests

to get values requires multiple responses. The packet size overall is much larger using the Batch

object, so more information is lost when the Batch response packet is lost.


In the non-Batch case, multiple packets have to be sent. Assuming a packet loss probability p,

the probability of losing at least 1 of x packets is given by:

ploss = 1− (1− p)x (6.6)

This is plotted for varying values of p in Figure 6.11.

Figure 6.11: The probability that information is lost for varying loss probability p.

It is obvious that the odds of losing some information grow rapidly for increasing number of

packets that have to arrive correctly. For the Batch object, only one packet has to arrive

successfully so this only increases linearly with the loss probability p.

6.2 Virtualization

In this second section, virtualizing legacy devices is evaluated. This is done by seeing how

many Docker instances can run simultaneously before it has a negative impact on the system’s

performance, i.e. LwM2M requests are served with a delay.

This was tested on two systems: a laptop running Ubuntu inside a VirtualBox and a Raspberry

Pi 3 (Model B) running Raspbian. The specifications of the laptop are:


• Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz (3 cores allocated for the VirtualBox)

• NVIDIA GeForce GTX 1060 (6 GB VRAM)

• 7981MiB RAM allocated for the VirtualBox

The specifications of the Raspberry Pi 3 (Model B) are:

• Quadcore ARM Cortex-A53, 1.2GHz

• Broadcom VideoCore IV

• 1GB LPDDR2 (900 MHz)

The CPU and RAM usage for increasing number of Docker instances running are visualized in

Figure 6.12.

Figure 6.12: The CPU and RAM usage for increasing number of Docker instances runningsimultaneously.

For the laptop, the RAM usage keeps increasing linearly until everything is in use. The CPU

usage stays at about 6% until the instances no longer fit inside the RAM. Once this point is hit,

the CPU usage climbs rapidly.

The Raspberry Pi demonstrates similar behaviour but it is obvious that it can handle fewer


simultaneous instances running. This is to be expected as its hardware is very limited. It can

handle about 25-30 instances before the system starts to become very strained.

Comparable behaviour is witnessed in the response times of handling the GET requests as

shown in Figure 6.13.

Figure 6.13: The time to complete GET requests for increasing number of Docker instancesrunning simultaneously.

For the laptop, the response times average around 20ms until the critical point where the in-

stances no longer fit inside the RAM, this is around 200-210 instances on this particular laptop.

From this point on, latency increases dramatically until about 120ms.

For the Raspberry Pi, the performance hit is much more dramatic. As soon as we have about

35 instances the time to complete requests sky-rockets: it becomes about 800 milliseconds. The

Raspberry Pi 3 (model B) can thus handle about 30 concurrent instances running.

Chapter 7

Conclusion and Future Work

This chapter concludes the dissertation by discussing some of the most important results and

making some suggestions for future work and areas that have room for improvement. It consists

of two sections, the first section discusses the Batch and Reverse Batch object. The second

section discusses the virtualization of legacy devices.

7.1 (Reverse) Batch

The main advantages of using the (Reverse) Batch object is the decreased number of packets

and total bytes that have to be sent and received. Instead of having to issue multiple requests

for reading from and writing to multiple resources, the Batch object allows this to be done using

a single request. The packets are larger overall using the Batch object though, as more data is

packed into a single packet.

This is something to take into account in environments with large packet loss: more data is

lost when a Batch response packet is lost. There is a flip side to this: using the Batch object,

either nothing is updated or all resources in the Batch configuration are: it is essentially an

atomic operation. This makes sure the object isn’t left in an invalid state.

The Batch object is much more efficient than sending separate requests overall. There are

some exceptions with relation to networks with a low MTU: a low MTU forces the usage of

block transfer, which might make the Batch object less efficient depending on the type and

number of resources.

47

Conclusion 48

When updating multiple resources within a single object, by either using the existing method

within LwM2M or the Batch object, the choice isn’t made as easily. The Batch object does not

require the resource URIs to be added to each request but this does not make the Batch object

the ideal solution in every case as the encoding isn’t as efficient in the Batch object.

The Reverse object is a useful extension on top of the Batch object. When an external system

wants to periodically poll resources, it makes use of Reverse Batch object. Instead of the

system having to send a request every so often, the Reverse Batch object sends these updates

automatically. This increases the efficiency even more.

7.1.1 Future work

There are certainly possibilities for future work. The most pressing one is to find a more efficient

encoding for the value resource of the Batch object. The value resource is a list of strings at

the moment, which is not efficient if the resources are actually integers, floating point numbers

or booleans. Using the Opaque data type could possibly improve the efficiency and it could

possibly use the TLV as an underlying format.

Not all types of resources are usable in combination with the Batch object as not all data

formats are supported as of the current implementation. Arrays and object links are not sup-

ported at the moment. A way of encoding these properly could be researched.

The Reverse object always encodes the data sent using the LwM2M JSON format. There is

no option to change this currently. A resource could be added that lets the user choose the type

of encoding used.

Another possible extension is to allow the Reverse Batch object to send periodic updates to

multiple external servers simultaneously.

7.2 Virtualization

Virtualizing legacy devices offers a wide array of possibilities. This allows these devices that

previously did not support LwM2M to interact with the rest of the network. As mentioned

before, this is not limited to only physical sensors but could be extended to databases, APIs,

etc.

Conclusion 49

It is implemented in such a way that as little as work as possible should be done by the developer

to extend this system for a new legacy device. The Adaptor is the only piece of code that should

be changed and everything else is handled through the custom JSON API.

7.2.1 Future work

For every virtualized sensor, a seperate Docker instance is ran. The alternative implementations

in Section 5.3.2 could be looked into. For example, the Adaptor and Virtual Device Manager

could be changed to support multiple Anjay connections. This way, multiple virtualized devices

could be run simultaneously without the slight overhead that the Docker instances incur.

Bibliography

[1] Amy Nordrum, “Popular Internet of Things Forecast of 50 Billion Devices by 2020

Is Outdated.” [Online]. Available: https://spectrum.ieee.org/tech-talk/telecom/internet/

popular-internet-of-things-forecast-of-50-billion-devices-by-2020-is-outdated

[2] imec, “City of Things.” [Online]. Available: https://www.imec-int.com/nl/what-we-offer/

innovation-services/city-of-things

[3] Open Mobile Alliance, “Lightweight Machine to Machine Technical Specification.”

[Online]. Available: http://www.openmobilealliance.org/release/LightweightM2M/V1

0-20170208-A/OMA-TS-LightweightM2M-V1 0-20170208-A.pdf

[4] P. van der Stok and C. Bormann and A. Sehgal, “PATCH and FETCH Methods

for the Constrained Application Protocol (CoAP).” [Online]. Available: https:

//tools.ietf.org/html/rfc8132

[5] Jaime Jimenez and Michael Koster and Hannes Tschofenig, “IPSO Smart Objects.”

[Online]. Available: https://tools.ietf.org/html/rfc8132

[6] Chonggang Wang and Dale N. Seed and Lijun Dong and Guang Lu and Michael F. Starsinic

and Nicholas J. Podias and Quang Ly and William R. Flynn IV and Zongrui Ding and Paul

L. Russel JR and Qing Li, “Method and apparatus forusing multiple universal resource

identifiers in M2M communications,” Patent US 2014/0 067 902, 08 13, 2013.

[7] Abdulkadir Karaagac and Floris Van Den Abeele and Jeroen Hoebeke,

“Challenges for Semantic LwM2M Interoperability in Complex IoT sys-

tems.” [Online]. Available: https://github.com/t2trg/2017-07-wishi/blob/master/slides/

21-Challenges-for-Semantic-LWM2M-Interoperability-in-Complex-IoT-Systems WI....pdf

[8] ——, “Challenges for Semantic LwM2M Interoperability in Complex IoT systems.”

[Online]. Available: https://github.com/t2trg/2017-07-wishi/blob/master/submissions/

21-Challenges-for-Semantic-LWM2M-Interoperability-in-Complex-IoT-Systems.pdf

50

https://spectrum.ieee.org/tech-talk/telecom/internet/popular-internet-of-things-forecast-of-50-billion-devices-by-2020-is-outdated

https://spectrum.ieee.org/tech-talk/telecom/internet/popular-internet-of-things-forecast-of-50-billion-devices-by-2020-is-outdated

https://www.imec-int.com/nl/what-we-offer/innovation-services/city-of-things

https://www.imec-int.com/nl/what-we-offer/innovation-services/city-of-things

http://www.openmobilealliance.org/release/LightweightM2M/V1_0-20170208-A/OMA-TS-LightweightM2M-V1_0-20170208-A.pdf

http://www.openmobilealliance.org/release/LightweightM2M/V1_0-20170208-A/OMA-TS-LightweightM2M-V1_0-20170208-A.pdf

https://tools.ietf.org/html/rfc8132



https://github.com/t2trg/2017-07-wishi/blob/master/slides/21-Challenges-for-Semantic-LWM2M-Interoperability-in-Complex-IoT-Systems_WI....pdf

https://github.com/t2trg/2017-07-wishi/blob/master/slides/21-Challenges-for-Semantic-LWM2M-Interoperability-in-Complex-IoT-Systems_WI....pdf

https://github.com/t2trg/2017-07-wishi/blob/master/submissions/21-Challenges-for-Semantic-LWM2M-Interoperability-in-Complex-IoT-Systems.pdf

https://github.com/t2trg/2017-07-wishi/blob/master/submissions/21-Challenges-for-Semantic-LWM2M-Interoperability-in-Complex-IoT-Systems.pdf

Appendices 51

[9] Open Mobile Alliance, “OMA LightweightM2M (LwM2M) Object and Resource

Registry.” [Online]. Available: http://www.openmobilealliance.org/wp/OMNA/LwM2M/

LwM2MRegistry.html

[10] Internet Engineering Task Force (IETF), “RFC 7252 - The Constrained Application

Protocol (CoAP).” [Online]. Available: https://tools.ietf.org/html/rfc7252

[11] A. Bhattacharyya and S. Bandyopadhyay and A. Pal and T. Bose, “Constrained

Application Protocol (CoAP) Option for No Server Response.” [Online]. Available:

https://datatracker.ietf.org/doc/rfc7967/?include text=1s

[12] G.Tanganelli and C. Vallati and E.Mingozzi, “CoAPthon: Easy Development of

CoAP-based IoT Applications with Python, IEEE World Forum on Internet of Things

(WF-IoT 2015).” [Online]. Available: https://github.com/Tanganelli/CoAPthon

[13] W. Felter, A. Ferreira, R. Rajamony, and J. Rubio, “An Updated Performance Comparison

of Virtual Machines and Linux Containers,” Austin Research Laboratory, Tech. Rep., 07

2014.

[14] Jeroen Hoebeke and Jetmir Hahibeqiri and Bart Moons and Abdulkadir Karagaac and Jen

Rossey, “Management of multi-modal LPWAN networks [Internal document].”

[15] Orne Brocaar, “LoRa Server, open-source LoRaWAN network-server.” [Online]. Available:

https://www.loraserver.io/

http://www.openmobilealliance.org/wp/OMNA/LwM2M/LwM2MRegistry.html

http://www.openmobilealliance.org/wp/OMNA/LwM2M/LwM2MRegistry.html


https://datatracker.ietf.org/doc/rfc7967/?include_text=1s

https://github.com/Tanganelli/CoAPthon

https://www.loraserver.io/

Appendix A

API between the Adaptor and

Virtual Device Manager

A.1 Registration

The registration request has to be sent from the Adaptor to the Virtual Device Manager, and is

done through a two-step process. First the Adaptor can request that some instances are created

in Anjay. This is done via the following packet structure:


4 {5 "object-id": 3360,


7 },8 {9 "object-id": 3303,


11 }12 ]

13 }14 }

52

Appendices 53

The VDM then responds a packet with the following structure:


4 {5 "object-id": 3360,

6 "instances": [0, 1]

7 },8 {9 "object-id": 3303,

10 "instance-ids": [0]

11 }12 ]

13 }14 }

The Adaptor should then send the resources, the instance ID can of course be one of the ones

that was just created:

Appendices 54

1 {2 "registration": {3 "resources": [

4 {5 "uri": "/a/b/c",

6 "value": 10,

7 "type": "integer",

8 "read-only": true

9 },10 {11 "uri": "/d/e/f",

12 "value": ["a", "list", "of", "strings"],

13 "type": "string",

14 "read-only": true

15 },16 {17 "uri": "/g/h/i",

18 "value": 3.14,

19 "type": "float",


21 },22 {23 "uri": "/j/k/l",

24 "values": [1, 2, 3, 4, 5],

25 "type":"integer",


27 }28 ]

29 }30 }

The type of the data is added as a field because in order to be able to pass the TLV data from

Anjay, the VDM needs to know the type of the resource it’s parsing. This is not a problem for

values that aren’t lists, but for lists the following problem is can occur: let’s say the initial value

of the list is an empty array, and we receive a TLV encoded non-empty list in an Observe update

from Anjay. Then it has no way knowing which type it has to parse the new list as. This is why,

for every resource in the registration request, the data type is (sometimes redundantly) stored.

Appendices 55

A.1.1 Possible return values

When the request was correctly received:

1 {2 "code": 200,

3 "message": "OK"

4 }

A.2 Delete an instance and references to its resources

This can be sent from the Adaptor to the Virtual Device Manager, the VDM then asks Anjay

to delete an object instance and delete its own reference to it.

1 {2 "delete": "/3360/0"

3 }



1 {2 "code": 200,

3 "message": "OK"

4 }

When the resource does not exist:

1 {2 "code": 404,

3 "message": "Not Found"

4 }

Appendices 56

A.3 Create an instance

This can be sent from the Adaptor to the Virtual Device Manager, the VDM then asks Anjay

to create an object instance.

1 {2 "create": "/3360"

3 }



1 {2 "created": "/3360/0"

3 }

A.4 Update the resource list by sending new resources of inter-

est

The Adaptor is allowed to send the following packet to the VDM in order to make it keep track

of extra resources.

Appendices 57

1 {2 "more_resources": {3 "resources": [

4 {5 "uri": "/m/n/o",

6 "value": 10,

7 "type": "integer",

8 "read-only": true

9 },10 {11 "uri": "/p/q/r",

12 "value": ["a", "list", "of", "strings"],

13 "type": "string",

14 "read-only": true

15 }16 ]

17 }18 }



1 {2 "code": 200,

3 "message": "OK"

4 }

A.5 Value updates

This can be sent from either the Adaptor to the Virtual Device Manager or the other way

around. This request represents a value changing in either the Adaptor or in the Virtual Device

Manager. An example request:

Appendices 58

1 {2 "update": {3 "uri": "/a/b/c",

4 "value": 10

5 }6 }



1 {2 "code": 200,

3 "message": "OK"

4 }

When the value was read-only:

1 {2 "code": 405,

3 "message": "Method Not Allowed"

4 }

When the resource does not exist:

1 {2 "code": 404,

3 "message": "Not Found"

4 }

extensions to lwm2m for improved efficiency and ......boolean, opaque, time and objlnk (object...

Documents