Communication protocols for mid-range mobile IoT devices1181232/FULLTEXT01.pdf · Transport(MQTT)...

INOM EXAMENSARBETE INFORMATIONSTEKNIK,AVANCERAD NIVÅ, 30 HP

, STOCKHOLM SVERIGE 2017

Communication protocols for mid-range mobile IoT devicesAnd their applicability to a publicly shared bikes platform

OSKAR LUNDH

KTHSKOLAN FÖR INFORMATIONS- OCH KOMMUNIKATIONSTEKNIK

i

Abstract

Oskar LUNDH

Communication protocols for mid-range mobile IoT

devices

Internet of Things, or the infrastructure of the information age society, is an expand-ing area of research. It is the idea that physical things that we have today, can beturned into devices by being connected to a network. The purpose of these devices isthrough more sensors and actuators, allow smarter and more robust infrastructure tobe built, as well as improving consumer devices interoperability.

This thesis will investigate the current state of the art application layer commu-nication protocols that have been developed with resource constrained mobile de-vices in mind. It will look specifically at high latency mid-range wireless cellularcommunication by investigating how the protocols affect energy consumption foran embedded Internet of Things device. This is done with the constraint that thesefindings needs to be applicable to the fifth generation of cellular networks, as wellas extensions to current generation standards. The application layer communica-tion protocols Constrained Applications Protocol(CoAP), Message Queue TelemetryTransport(MQTT) and Hypertext Transfer Protocol(HTTP) used on multiple modemmodules, are investigated in a quantitative approach in deductive survey experiments,testing a variety of what is concluded to be typical sensor and actuator scenarios. Thegoal with the survey, is to ultimately select the protocol that shows to be the mostsuitable for a project to build a prototype platform for embedded mobile devices inthe shape of publicly shared bikes in a city. This prototype is described and its ar-chitecture and design decisions are presented and argued for. The survey discoversthat CoAP is the most suitable protocol for the purpose of the thesis, and proceeds toshow how it is applied to the described platform.

Keywords: Internet of Things, Fifth Generation, Energy Consumption, Embed-ded Mobile Device, City Bikes, CoAP, MQTT, HTTP

ii

Contents

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4.1 Benefits, Ethics and Sustainability . . . . . . . . . . . . . . 31.5 Methodology and Methods . . . . . . . . . . . . . . . . . . . . . . 4

1.5.1 Philosophical Assumptions . . . . . . . . . . . . . . . . . . 41.5.2 Research Methods . . . . . . . . . . . . . . . . . . . . . . 41.5.3 Research Approaches . . . . . . . . . . . . . . . . . . . . . 51.5.4 Research Strategies . . . . . . . . . . . . . . . . . . . . . . 5

1.6 Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.7 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.8 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Communication Standards and Embedded Systems 82.1 Mid-Range Communication Standards . . . . . . . . . . . . . . . . 8

2.1.1 Cellular . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Global System for Mobile Communication . . . . . . . . . 9General Packet Radio Service . . . . . . . . . . . . . . . . 9Fifth Generation . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.2 Low Power Wide Area Network . . . . . . . . . . . . . . . 9LoRa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Sigfox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Narrow Band - IoT . . . . . . . . . . . . . . . . . . . . . . 10Extended Coverage - GSM-IoT . . . . . . . . . . . . . . . 10

2.2 Transport Layer Protocols . . . . . . . . . . . . . . . . . . . . . . 11Transmission Control Protocol . . . . . . . . . . . . . . . . 11User Datagram Protocol . . . . . . . . . . . . . . . . . . . 11

2.3 Communication Protocols . . . . . . . . . . . . . . . . . . . . . . 12Extensible Messaging and Presence Protocol . . . . . . . . 12

iii

Data Distribution Service . . . . . . . . . . . . . . . . . . . 12Protocol buffers . . . . . . . . . . . . . . . . . . . . . . . . 12Hypertext Transfer Protocol . . . . . . . . . . . . . . . . . 13Message Queue Telemetry Transport . . . . . . . . . . . . 13Constrained Application Protocol . . . . . . . . . . . . . . 13

2.3.1 Security Protocols . . . . . . . . . . . . . . . . . . . . . . 14TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4 Embedded Systems . . . . . . . . . . . . . . . . . . . . . . . . . . 14Analog Digital Converter . . . . . . . . . . . . . . . . . . . 15AT Commands . . . . . . . . . . . . . . . . . . . . . . . . 15

2.4.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Atmel SAM D21 . . . . . . . . . . . . . . . . . . . . . . . 15INA168 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.5 Global Positioning System . . . . . . . . . . . . . . . . . . . . . . 162.6 Virtual Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.7 Elixir, Erlang and OTP . . . . . . . . . . . . . . . . . . . . . . . . 162.8 Conventions and Terminology . . . . . . . . . . . . . . . . . . . . 17

Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Connection . . . . . . . . . . . . . . . . . . . . . . . . . . 17Endpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.9 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.10 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 Models and Methods 203.1 Development Methodology . . . . . . . . . . . . . . . . . . . . . . 20

Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Waterfall . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Lean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2 Data Collection Methods . . . . . . . . . . . . . . . . . . . . . . . 223.3 Data Analysis Methods . . . . . . . . . . . . . . . . . . . . . . . . 233.4 Quality Assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

iv

4 Platform Prototype for Publicly Shared City Bikes 254.1 Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1.1 Embedded device . . . . . . . . . . . . . . . . . . . . . . . 264.1.2 Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Inbound Node Worker . . . . . . . . . . . . . . . . . . . . 29Outbound Node Worker . . . . . . . . . . . . . . . . . . . 29Inbound Core Worker . . . . . . . . . . . . . . . . . . . . . 29Outbound Core Worker . . . . . . . . . . . . . . . . . . . . 29

4.1.3 Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.2 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5 IoT Communication Protocol Survey 325.1 Survey Implementation . . . . . . . . . . . . . . . . . . . . . . . . 32

5.1.1 Implementation Validation . . . . . . . . . . . . . . . . . . 345.2 Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.3 Application layer protocol . . . . . . . . . . . . . . . . . . . . . . 365.4 Transport layer protocol . . . . . . . . . . . . . . . . . . . . . . . . 365.5 GSM/GPRS Modules . . . . . . . . . . . . . . . . . . . . . . . . . 375.6 Protocol State-fulness . . . . . . . . . . . . . . . . . . . . . . . . . 375.7 Packet Logger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.8 Survey Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . 375.9 IoT communication experiments . . . . . . . . . . . . . . . . . . . 38

Small Packet Test . . . . . . . . . . . . . . . . . . . . . . . 38Large Packet Test . . . . . . . . . . . . . . . . . . . . . . . 39Multiple Small Packets Test . . . . . . . . . . . . . . . . . 39

6 Communication Protocol Energy Consumption Comparison 406.1 Small Packet Test Results . . . . . . . . . . . . . . . . . . . . . . . 41

A6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41SIM800L . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.1.1 Small Packet Test Evaluation . . . . . . . . . . . . . . . . . 426.2 Large Packet Test Results . . . . . . . . . . . . . . . . . . . . . . . 43

A6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43SIM800L . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.2.1 Large Packet Test Evaluation . . . . . . . . . . . . . . . . . 446.3 Multiple Small Packets Test . . . . . . . . . . . . . . . . . . . . . 45

A6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45SIM800L . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.3.1 Multiple Small Packets Test Evaluation . . . . . . . . . . . 46

v

6.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

7 Communication Protocol for Publicly Shared City Bikes 48Unlock . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Lock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

8 Conclusions 518.1 Protocol Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518.2 Platform Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . 528.3 Comparison with related work . . . . . . . . . . . . . . . . . . . . 538.4 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Bibliography 55

A Appendix A 61A.1 Communication Protocols Binary Sequences . . . . . . . . . . . . . 61

A.1.1 Small Packet Test Binary Sequences . . . . . . . . . . . . . 61MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

A.1.2 Large Packet Test Binary Sequences . . . . . . . . . . . . . 61MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

A.1.3 Multiple Small Packets Binary Sequences . . . . . . . . . . 62MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

vi

List of Figures

2.1 Simplified overview of the internet protocol suite[25] . . . . . . . . 18

4.1 Platform Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 254.2 Device Broker Sequence . . . . . . . . . . . . . . . . . . . . . . . 264.3 Embedded Device Activity . . . . . . . . . . . . . . . . . . . . . . 274.4 Broker Supervision Tree . . . . . . . . . . . . . . . . . . . . . . . 284.5 Broker Core Sequence . . . . . . . . . . . . . . . . . . . . . . . . 30

5.1 Circuit for the experiments measurement platform . . . . . . . . . . 35

6.1 Transmission sequence from small packet test run on A6 . . . . . . 416.2 Transmission sequence from small packet test run on SIM800L . . . 426.3 Transmission sequence from large packet test run on A6 . . . . . . 436.4 Transmission sequence from large packet test run on SIM800L . . . 446.5 Transmission sequence from multiple small packets test run on A6 . 456.6 Transmission sequence from multiple small packets test run on SIM800L 46

7.1 CoAP unlock Request . . . . . . . . . . . . . . . . . . . . . . . . . 497.2 CoAP lock Request . . . . . . . . . . . . . . . . . . . . . . . . . . 497.3 CoAP report Request . . . . . . . . . . . . . . . . . . . . . . . . . 50

vii

List of Tables

2.1 Simplified TCP Header . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Simplified UDP Header . . . . . . . . . . . . . . . . . . . . . . . . 12

5.1 Kanban board, after first requirement gathering. . . . . . . . . . . . 335.2 Kanban board, after 160 hours of development. . . . . . . . . . . . 335.3 Kanban board, after second requirements gathering . . . . . . . . . 335.4 Protocol Transports . . . . . . . . . . . . . . . . . . . . . . . . . . 365.5 GPRS modules uplink and downlink specifications . . . . . . . . . 375.6 Small Packet Payload . . . . . . . . . . . . . . . . . . . . . . . . . 385.7 Large Packet Payload . . . . . . . . . . . . . . . . . . . . . . . . . 395.8 Multiple Small Packets Payload . . . . . . . . . . . . . . . . . . . 39

6.1 Data from small packet test run on A6 . . . . . . . . . . . . . . . . 416.2 Data from small packet test run on SIM800L . . . . . . . . . . . . 426.3 Data from large packet test run on A6 . . . . . . . . . . . . . . . . 436.4 Data from large packet test run on SIM800L . . . . . . . . . . . . . 446.5 Data from multiple small packets test run on A6 . . . . . . . . . . . 456.6 Data from multiple small packets test run on SIM800L . . . . . . . 46

viii

List of Abbreviations

5G Fifth GenerationADC Analog Digital ConverterBER Bit Error RateCoAP Constrained Application ProtocolDDS Data Distribution ServiceDTLS Datagram Transport Layer SecurityEC-GSM Extended Coverage Global System for Mobile communicationGPRS General Packet Radio ServicesGPS Global Positioning SystemGSM Global System for Mobile communicationHTTP Hyper Text Transfer ProtocolIoT Internet Of ThingsIP Internet ProtocolJSON Java Script Object NotationMQTT Message Queue Telemetry TransportNB-IoT Narrow Band IoTOSI model Open System Interconnection modelOTP Open Telecom PlatformRSSI Received Signal Strength IndicatorTCP Transmission Control ProtocolTLS Transport Layer SecurityUDP User Datagram ProtocolVM Virtual MachineXMPP Extensible Messaging Presence Protocol

ix

List of Symbols

U voltage VI current AR resistance Ω

P power W (V×A)J joule J (W× s)

1

Chapter 1

Introduction

Internet of things (IoT) is the concept that physical things becomes devices whenconnected to a network for the purpose of exchanging data with other devices on thisnetwork.It is to be used either as a way to connect consumer applications for the purpose ofinteroperability, or provide infrastructure in what is to be regarded as a informationage society [1]. Although it was conceptualized in the 80s [2], it is only in recentyears that the technology has advanced enough that the concept has become trulyavailable to implement. This is because it is now possible to build devices withenough performance, and at the same time low enough power consumption and pricefor it to be available at a large scale. The required infrastructure for these devicesto all be connected is starting to get in place. Already feasible areas for applied IoTis home automation, connected factories, monitoring system, smart electricity grids,and consumer applications [3].It is estimated that by the year 2020 the number of connected IoT devices will bearound 26 billion [4].

1.1 Background

In order to support all those expected billions of connected devices. New standardsdesigned with this scale in mind are required. Internet Protocol version 6(IPv6) wasneeded for each device to be individually addressable [5]. Along with this, advance-ments in the field of embedded systems was also needed.This field has moved from embedded processors capable of performing small tasks,while still with a high price-tag. To having large processing power, while being en-ergy efficient and cheap, making it deployable at a large scale [6].There is no opinion of how a IoT device is connected. Though it is reasonable toassume that the mediums will be either wired or ranged. In the context of this the-sis, range can be interpreted as radio signal based communication. The available

2 Chapter 1. Introduction

communication technologies using these mediums are often divided into four areas[7]:

• Wired: Cable

• Short-range: Wifi, Mesh-networks

• Mid-range: Cellular networks/Wireless mobile networks

• Long-range: Satellite

Since it is predicted to be a very lucrative area [4], there are already a number ofcompeting standards and implementations on all of these mediums, along with newones being drafted.

As mentioned, the continued growth of the amount of connected devices is de-pendent on the continuous development of infrastructure. A large piece in the expan-sion of mid-range devices relies on the release of the fifth generation(5G) standardof cellular networks and the extension of already existing network standards such asNarrow Band IoT (NB-IoT) or Extended Coverage GSM(EC-GSM) to fit with therequirements of IoT [8][9][10].Though these new standards are added to the mid-range wireless networks, they willall still adhere to the fundamentals of the internet architecture, allowing for the ex-ploration of network layers that will remain unaffected without risking that the con-clusions become obsolete once newer standards are introduced.Communication is a key aspect for any IoT device. Being able to do this efficientlyand reliably for an extended period of time is likely to have a large impact on thedesign of any solution architecture involving IoT in the future. While a IoT devicemay refer to many kinds of devices, this thesis is concerned with embedded IoT de-vices, that needs to operate as a mobile mid-range node in a network. This devicecan switch between active and passive mode, where active is likely when measure-ments are done, in addition to transmitting these measurements on the network. Itis expected that this device has a long period of operation, meaning that it does notneed to be serviced or have maintenance performed regularly. For this to be possibleit needs to have a low energy consumption when passive, dormant or sleeping as itis commonly referred to. But it is also important to be as efficient as possible whenactive.

1.2. Problem 3

1.2 Problem

What communication protocol can be used within the context of energy conservativemid-ranged embedded mobile devices, that will continue to be relevant with nextgeneration infrastructure and hardware?

1.3 Purpose

The purpose of this thesis is to present a communication protocol that can be usedfor mid-range embedded mobile devices acting as the network platform for publiclyshared city bicycles.

1.4 Goal

This thesis presents a communication protocol that makes the active mode of a mo-bile embedded IoT device as efficient as possible for high latency mid-range com-munication, while adhering to the constraint of energy efficiency and future compat-ibility. As well as a description of how it could be applied in a prototype platform forpublicly shared bikes.

1.4.1 Benefits, Ethics and Sustainability

As with all new technology focused on interoperability it is important to rememberto weight the gain of gathering more data and the improvements that it can bring,versus the risk of that data being used maliciously in the wrong hands.A question in IoT that is rarely addressed and not yet solved on a political or corpo-rate level, is the question of who owns the data being generated by these devices. Forexample, a user owns a device which produces some kind of spatial-temporal data,such as timestamped Global Positioning System (GPS)-coordinates, that data is thensent using cellular networks to a cloud based service that stores it. All tree actors: theuser, the cellular network operator and the cloud service, are needed for the productand reflects a typical real world setting.Is it the user which produces the data, the cellular network operator, or the cloudservice provider that decides how the data can used?

With IoT the amount of sensor will eventually reach the amount where collectingdata will enable new markets [4]. The most prevalent of these is the usage of socalled metadata, where a collector acquire so much data from different sensor that it


can start making new assumptions and associations as part of big data analysis. Sinceit’s a derived usage of a users produced data, there is the argument that it’s intrudingon a users privacy, as the gain is not directly obvious to the user.

1.5 Methodology and Methods

Research methods are the core of a dissertation. Correctly choosing and applyingthem is the main priority in any thesis. It is important to have stated the researchmethods and their steps towards reaching results before conducting the study [11].This section will introduce and argue about this thesis methods for the purpose ofestablishing the authors interpretation, to bring forth any difference in opinion withthat of the reader. In chapter 3, the chosen methods are presented along with theused development methodologies and frameworks used to implement and executethe chosen methods.

1.5.1 Philosophical Assumptions

The philosophical assumption is which state of mind or way of interpreting the worldthe researcher uses.

• Positivism

• Realism

• Interpretivism

• Criticalism

Positivism states that reality is independent of the observer and the researcher candeductively draw conclusions.Realism states that the observed reality is the assumed reality and observed phenom-enas are regarded as valid.Interpretivism states that reality is only perceived through subjective social observa-tions.Criticalism states reality is the result of social and history produced by people, mean-ing that any conclusions can only be derived by these.

1.5.2 Research Methods

Research methods dictate in what manner individual tasks in the thesis are conducted.

• Experimental or Quantitative

1.5. Methodology and Methods 5

• Non-experimental

• Descriptive

• Qualitative

• Analytical

• Fundamental/Basic

• Applied

• Conceptual

• Empirical

Quantitative studies relation between data and its changes. Non-experimental de-scribes behaviors. Descriptive research looks at phenomena and characteristics ofsituation in a statistical manner usually through questionnaires. Analytical researchtests hypotheses to verify assumptions made based on previous insight. Fundamen-tal research tests new ideas without any predefined hypotheses to generate new ideas.Applied research is based on fundamental research to solve a previously known prob-lem. Conceptual research looks to find new concepts or interpret existing. Empiricalresearch derives knowledge from experience or analyzing data from experiments.

1.5.3 Research Approaches

Research approaches describes in what steps a logic conclusion is accepted.

• Inductive approach

• Deductive approach

• Abductive approach

Inductive reasoning looks at providing enough evidence of a probable conclusion.Deductive reasoning logically looks at previous conclusion to determine if somethingis true. Abductive reasoning uses a combination of inductive and deductive.

1.5.4 Research Strategies

Research strategies are the methodologies to retrieve and use the data. The quantita-tive strategies are

• Experimental


• Ex post facto

• Surveys

• Case Study

Experimental research is data-driven where data is collected and used to verify ahypotheses. Ex post facto is the same as experimental, but is done after the data iscollected. Surveys research looks at frequency and patterns in collected data. Casestudy research is a empirical investigation of of a phenomena.

The qualitative strategies are

• Exploratory

• Grounded theory

• Ethnography

Exploratory research is often done through surveys, and is used to provide insightrather than proof. Grounded theory research looks to find theories in data. Ethnog-raphy is based in anthropology and studies social constructs to research cultural phe-nomenas.

1.6 Stakeholders

This thesis will be done independently, but it’s results and conclusions will be pre-sented and used by Mobiento/Deloitte DigitalMobiento is a Stockholm based digital consulting agency with about 40 employees.They have a background in mobile solutions, and was recently acquired by DeloitteDigital. They are as a traditional digital agency helping customers in digitalizingtheir business and are invested in finding new markets for them to grow. As part ofthis initiative, they are looking to bring IoT solutions on a prototype level for theircustomers to try out concepts and ideas before moving further.

Throughout the thesis work, the industrial supervisor has been Zaidin Amiot ofMobiento.

1.7 Delimitations

IoT is still to be regarded as volatile research field, requiring any undertaker to keepin mind that any chosen solution might not be relevant in a few years [12]. To miti-gate the risk of becoming obsolete the thesis will focus on protocols residing in the

1.8. Outline 7

application layer, and consequently it’s neighboring layers [13], defined in the Inter-net Suite and rely on the assumption that the cornerstones that make up the interneton the lower layers will remain practically the same. It will focus and argue aboutthe alternatives from the viewpoint of mid-range mobile devices. The solutions dis-carded or concluded to be inferior, might be viable for other forms of IoT. In a realworld scenario, the decision of which protocol to use in a product, would not exclu-sively rely on data from test scenarios as presented. It would also take into accountthe popularity of a protocol, and as extension of this it widespread and acceptance asa standard, as well as it’s complexity of implementation and the subjective opinionof the protocols design.For this thesis goal the decision of preferred solution is taken with in the context thatit’s to be for the prototype project of publicly shared city bikes with the corroborationof the results of the survey.

1.8 Outline

In chapter 2, the technical background to the subject is explored, a thorough investi-gation of the standards and protocols related to IoT is given. Previous research in thefield is presented.Chapter 3 presents the scientific methodology for the thesis work and software de-velopment methods used to implement protocols and to perform the tests.In chapter 4 a description of a prototype of a platform for publicly shared bikes isgiven.In chapter 5, a description of the work process in developing the measurement ex-periments and the protocol implementations is presented. Then the implementationof the test platform is described, along with descriptions of the different test scenar-ios that are looked at in the results and evaluation chapters. In chapter 6, the resultsfrom the tests described in chapter 5 are presented and evaluated. In chapter 7 it isshown how the results from chapter 6’s survey are applied to the platform prototypefor shared bikes described in chapter 4.In chapter 8, conclusions of the thesis is presented and future work is suggested.

8

Chapter 2

Communication Standards andEmbedded Systems

The purpose with the theoretical background is to provide a context and to give back-ground to the decision made in later chapters. The chapter begins with a descriptionof the communication standards related to mid-range IoT devices. Then the differenttransport layer protocols are described to allow the next section with the applicationlayer protocols to be explained. Next the current field of hardware is described, to-gether with brief introduction to the basic concepts of embedded systems. This willprovide background about the choices made during the construction of the test plat-form and give the reader some context on a potential environment for the protocolsbeing tested.To give foundation of some of the concepts discussed in chapter 4, there then fol-lows sections about specific technologies and programming languages used. This isfollowed by a section with this thesis used conventions and terminology. In the endof this chapter, a summary of the information provided and the work related to thisthesis subject is presented.

2.1 Mid-Range Communication Standards

There are several means of communication available today when developing an IoTproduct. Since this thesis will focus on the mid-ranged communication, the mostcommon mid-range alternatives will be described.

2.1.1 Cellular

Cellular networks is a wireless communication network with divided cells in a grid.Each cell is an abstraction of a fixed location antenna(base station), which a devicecommunicates through to the network. There are multiple communication protocolsbuilt for cellular networks that have evolved through the years.[14] In the following

2.1. Mid-Range Communication Standards 9

sections the standards Global System for Mobile Communication(GSM), GeneralPacket Radio Service(GPRS), Fifth Generation(5G) will be described.

Global System for Mobile Communication

Global System for Mobile Communications(GSM) was introduced in 1991 to de-scribe the second generation(2G) of digital wireless communication, replacing thefirst generation(1G) analog systems. It quickly became a standard for mobile com-munication with a 90% market share [15]. It was was eventually extended to allowfor data communication through package switching by the GPRS/EDGE protocol.

General Packet Radio Service

General Packet Radio Service(GPRS) is a 2G communication protocol for data trans-port. It allows the usage of IP packages to be sent through mobile networks. Itextends GSM to allow services such as SMS, MMS and communication with theInternet.[16][17]

Fifth Generation

The fifth generation(5G) of the mobile communication standard. Improving on thethird and fourth in terms of data bandwidth, but is the first generation to have designaspects with IoT in mind. Its standards draft is expected to be done during 2017, anddeployed at the earliest in 2019.[18]

These standards are all part of the same family of cellular networks. Together theyoffer mobile cellular devices coverage on almost any populated place on earth[19],and as such it is unusual for a cellular device sold to day, to not support all of thesestandards. This makes it the most adopted communication standard on the market.For IoT systems this is an attractive feature, since high availability is a key aspect ofmobile devices.

2.1.2 Low Power Wide Area Network

Low Power Wide Area Network(LPWAN) is commonly used acronym for wirelesscommunication operating in comparable or compatible fashion as cellular networks.Its definition is vague and the acronym is to be used as category denotation. It is oftenused in IoT context to denote a wide area network such as GSM but that is designedwith low power usage in mind.

10 Chapter 2. Communication Standards and Embedded Systems

LoRa

LoRa or LoRaWAN is a suggested specification for LPWAN. It is maintained by acollaboration of companies but only has one manufacturer of the antennas that areused for the physical communication.[20]

Sigfox

Sigfox is a company that provides a complete LPWAN solution. They are currentlythe market leader for LPWAN based IoT solutions. They only offer proprietary solu-tions.[21]

Narrow Band - IoT

Narrow band IoT(NB-IoT) is a subset of the 5G LTE(Long Term Evolution) standardreleased in advance of 5G as an upgrade to 4G networks [8]. It is designed explicitlyfor IoT and is meant to function as a LPWAN. It uses the already existing cellularGSM network infrastructure and is supposedly a software upgrade to existing basestations. It allows for cheaper and more energy efficient hardware though at thetradeoff of much lower data transmission rates. It has already been deploy in selectcountries and over 30 more countries will join during 2030.[22][23]

Extended Coverage - GSM-IoT

Extended Coverage GSM IoT(EC-GSM-IoT) is a proposed extension to the 2G GSMnetworks [8]. It is to fill the same role as NB-IoT but for the older network standardto cover markets that do not have 4G network coverage and allow these IoT basedsolutions. It is effort to repurpose the older soon to be obsolete networks.

These network standards are either meant to provide an alternative to establishedcellular standards for energy efficient IoT devices in mind. Or they are the extensionsof said established cellular standards mean to bridge the gap for energy efficient IoTdevices. As stated before, the 2G, 3G, 4G networks offer the highest availability,since they are already well established standards. And with the advancements inenergy consumption being purposed with the 5G standard, it likely that NB-IoT orEC-GSM become well adopted standards in IoT solution architectures.

2.2. Transport Layer Protocols 11

2.2 Transport Layer Protocols

In the Internet protocol suite[24] and Data layer in the OSI model[25], there are be-low the Application layer, the Transport layer. It provides a defined way of transfer-ring sequences of data from a source to a destination. The different transports layerprotocols have different quality of service, meaning that as a consequence of theirdifferent strategies in transporting data, they have different guarantees about packetordering and packet consistency. The different protocols also allows for differentsecurity to be built on top of them.

Transmission Control Protocol

Transmission Control Protocol(TCP) provides reliable, ordered and error-checkedpacket transmission. This allows the Application layer to assume that any data sentand received is usable without further consistency checking.It was the original network protocol developed to be used along with the InternetProtocol(IP), commonly called TCP/IP, used interchangeably to refer to the Internetprotocol suite. Still today most Internet applications relies on TCP for communica-tion.TCP is session based, with a handshake procedure in the beginning of connection. Italso uses acknowledge messages to confirm received data.[26]

All packets sent through TCP are wrapped with a TCP header.

TABLE 2.1: Simplified TCP Header

source port destination port

sequence number

acknowledgement number

data offset reserved window size

checksum urgent pointer

optionsThe header contains all the meta data needed for the TCP protocol. TCP packet canbe larger but is usually restricted in size so they fit into a single Internet Protocol(IP)packet. Packets are sent asynchronous but multiple at a time in a so called win-dow, the guaranteed ordering is done by reordering them on the destination by theirsequence number.

User Datagram Protocol

User datagram protocol(UDP) defined so called datagrams that can be sent throughthe Internet protocol suite. It does not require any previous communication with thedestination. Because of this, it has low overhead and requires minimal setup to use. It


does not have the same quality of service as TCP, and does not provide any guaranteesfor packet ordering or its consistency, other than a checksum validation per packet.Because of this it is commonly used in data streaming where individual packets arenot critical, or considered relevant after the subsequent packet is transmitted.[27]All packets sent trough UDP are wrapped with a UPD header.

TABLE 2.2: Simplified UDP Header

source port destination port

length checksumThe UDP header is basically a simplified version of TCP, since UDP does not offeras many features.

2.3 Communication Protocols

In the following sections, the application layer protocols of the OSI network stackthat are relevant for the thesis are described [13]. These are Extensible Messagingand Presence Protocol(XMPP), Data Distribution Service(DDS), Protocol buffers,Hypertext Transfer Protocol(HTTP), Message Queue Telemetry Transport(MQTT)and Constrained Application Protocol(CoAP)

Extensible Messaging and Presence Protocol

Extensible Messaging and Presence Protocol(XMPP) uses Extensible Markup lan-guage (XML) to transfer data. Originally designed for and most often used in instantmessaging applications or similar web services. It’s maintained through a open stan-dard, it has a focus on being extensible[28].

Data Distribution Service

Data Distribution Service(DDS) is designed for real time Machine to Machine(M2M)communication using publish/subscribe with scalability in mind. It is commonlyused in factory or airline settings[29].

Protocol buffers

Protocol buffer refer to simple but automated serialization of data of a predefinedformat. It is used a efficient and easy way for packeting data models where no over-laying application protocol is needed, and the data just needs to be transmitted froma known source to a know destination, without any standardization[30]. Protocolbuffers can be used directly together with any transport protocol, and can also be

2.3. Communication Protocols 13

used in combination with other application protocols to serialize payload data effi-ciently.

Hypertext Transfer Protocol

Hypertext Transfer Protocol(HTTP) is a simple yet flexible communication protocol.It transmits data in structured text separating different parts with newlines. HTTPis always operated by a request followed by a response. There are several types ofrequest in the HTTP, the two most common are GET and POST. GET is expected tonever have any side effects on the receiver, i.e. it should not be stateful and affectsubsequent requests. POST however is expected allowed to have lasting effect onthe receiver state. HTTP uses TCP as transport layer, and commonly HTTP onlymakes one request per connection, and it is then closed after a response is received.But it is allowed to keep the connection open and make multiple requests on reusedconnection. Its most common application today is as the foundation of the WWW,for which it was originally built and intended for, but has since been applied to otherareas[31].

Message Queue Telemetry Transport

Message Queue Telemetry Transport(MQTT) is a M2M publish/subscribe commu-nication protocol. It uses TCP as transport layer and is designed to be efficient inoverhead size and to be implemented on small devices. It relies on a message brokerto distributes messages between connected nodes. MQTT have several packet typesthat allows different operation strategies. The most common types are Connect, Dis-connect, Subscribe, UnSubscribe, Publish. Any connection must be initiated by aConnect packet being sent, and any disconnection must be preceded by a Disconnectpacket being sent. A connected node can subscribe to as many topics it wants, andwill while its connected receive any Publish packet sent to that topic[32].

Constrained Application Protocol

Constrained Application Protocol(CoAP) is a communication protocol designedspecifically to be used within constrained environments, and as such for IoT ap-plications. It is designed to have low overhead but at the same time easily parseablefor embedded devices, by only dealing with binary data and fixed header sizes. Thisin contrast to protocols such as HTTP which aims to be human readable. It has bor-rowed several key concepts from HTTP, it has Uniform Resource Identifiers(URI)to locate resources and content-types to allow flexibility in client and server inter-operability. And as an extension of this interoperability it has support for service


and resource discovery[33]. CoAP is transport protocol agnostic, even though thespecification mentions UDP as the main transport layer for the current version. Itdoes not have any requirements of a connection being established, allowing the im-plementer to decide how the individual packets should be sent. As a result from thisthere are already several additional specification drafted to specify how to use CoAPover other transports such as TCP or Short Message Service(SMS)[34][35].

2.3.1 Security Protocols

Security protocols provide secure communication between two or more nodes on anetwork. On a network as large and distributed as the Internet it is crucial for anynode to have the capability to communicate securely. Modern security protocols arebased on encryption with decrypt keys being distributed previously or by a trustedthird party.

TLS

Transport Layer Security(TLS), also referred to as Secure Socket layer(SSL), is usedto secure TCP, allowing dependent application layer protocols such as HTTP, XMPPand MQTT communicate securely[36].

DTLS

Datagram Transport Layer Security(DTLS) provides the same security as TLS butfor UDP instead. It is based on TLS, and in order to provide the same guaranteesas TLS, it has to add functionality on top of the UDP transport, such as packetreordering and packet loss detection. Despite these features added, that somewhatcontradicts the usage of UDP, it manages to avoid stream framing delays[37].

Both TLS and DTLS add so called overhead to any communication they are secur-ing. More data needs to be sent per packet as well as when establishing connec-tion[38][39]. Since both are based on cryptography which requires calculations tobe performed by all parties upon communication it is not a given that it can be easilyimplemented on constrained devices such as embedded systems.

2.4 Embedded Systems

For most IoT solutions, some parts will rely on so called embedded systems. Theseare the parts that are either constrained in time, computational power, or available

2.4. Embedded Systems 15

battery power. What characterizes an embedded system, is that it is dedicated to asingle purpose, only being a part of a larger solution. In the context of IoT this wouldusually be a node in the network as a sensor or actuator.

Analog Digital Converter

Analog to Digital Converter(ADC) is piece of hardware that convert analog signal toa digital value. This is achieved by the hardware having comparators that differen-tiate incremental steps in voltage level. The digital values resolution or bit length isdetermined by the amount and size of these steps. When using a ADC it is commonto also note the sample rate, i.e. rate at which the hardware can be used to measure,this rate is determined by a combination of the quality of the ADC hardware and theresolution.

AT Commands

Hayes command set, most commonly referred to as AT(attention) commands, is acommunication protocol to communicate and control modems through a serial con-nection. It is still used by mobile GSM modules due to it’s simplicity[40].

2.4.1 Hardware

The most energy efficient embedded systems, are so called Micro-controllerUnits(MCU). That uses simplified computational units to perform its tasks. It usu-ally does not have any operating system, but instead runs instructions directly insequence, allowing it to do a single tasks in predictable real-time deadlines. Tradi-tionally this group of computers have had constrained computational power or mem-ory in order to be used in IoT scenarios. But in recent years large headway has beenmade and it is now trivial to fit the networks protocol stacks needed for the Interneton a single device. Some of the currently popular platforms are the ARM Cortexarchitecture, with the baseline model M0 and M3 being designed for low power em-bedded systems[41].

Atmel SAM D21

The Atmel SAM D21 is a series of ARM M0 based micro-controllers that have 32bitaddressing, 128 KB flash memory.[42]


INA168

The INA168 is a current shunt monitor. It allows for easy conversion betweenvoltage drop across a resistor that is placed in series with a load that one wants tomeasure the current going through it. [43]

Embedded systems are a prevalent in all areas of technology today, as less than onepercent of all computers today are inside consumer electronics such as Personal Com-puters, smart-phones, etc.[44] Most computers are instead of the shape of embeddedsystems, hidden in everything, playing a large part of the infrastructure of the infor-mation society. This thesis utilizes embedded systems both for the platform whichexperiments are conducted on, but also as the target platform of the device for whichto measure against regarding communication protocol applicability.

2.5 Global Positioning System

Global Positioning System(GPS) is a satellite based navigation system. It operatesby having a large number of satellites spread out in known geo-stationary orbitalposition, all equipped with synchronized atomic clocks. These satellites transmitstheir current time using radio signals at fixed intervals, which a GPS receiver candetect. If the receiver is acquiring signals from four or more satellites it can use thesent times to triangulate its own position[45].

2.6 Virtual Machine

A Virtual Machine(VM) is a emulator of a computer system architecture, it can eitherbe a representation of an existing hardware architecture or a virtual architecture onlyexisting in the context of the virtual machine[46]. It has a wide range of applications,where the most common are either as virtual sandboxes, where code can executesecurely and isolated from the host system. Or as abstraction layers for languagesthat does not need to about hardware architecture.

2.7 Elixir, Erlang and OTP

Erlang and Elixir are programming languages that run inside the Beam VM[47][48].The Beam VM is an environment that acts as it’s own operating system, providinga abstraction layer from the hardware where through some intermediate steps, Elixirand Erlang can execute. Because of this shared environment, Elixir code can access

2.8. Conventions and Terminology 17

Erlang libraries such as the Open Telecom Platform(OTP)[49]. OTP defines designpatterns and process structures for building robust and fault tolerant applications. Itwas originally developed for and is still widely used in cellular networks, and havebeen in use for almost 30 years[50].

2.8 Conventions and Terminology

In the following sections certain conventions and terminologies will be used that havea tendency to mean different things to different authors, to avoid any confusion, thissection provides this thesis intended interpretation.

Node

A indedependent actor working as part of a larger network. It can either only send orreceive data, or do both.

Connection

An interaction between two nodes in a network. A connection can be establishedbetween nodes to perform a single operation, or sustained and reused for multipleoperations.

Endpoint

A location on a node, identifying a resource or action trigger.

Client

An initiator of a connection between two nodes. Where the other node is centralizedin a way that that it has multiple client nodes connecting to it.

Server

A node that receives connections from multiple client nodes.

2.9 Related work

Many new standards that have been explained in this chapter have emerged or areemerging in the LPWAN category of mid-ranged networks, such as Lora and Sig-Fox. Along with these are EC-GSM as a extension of the existing GSM networksto better fit the needs of future IoT devices, and NB-IoT which is the addition to 4g


networks for the same purpose. Both of these standards will in some way upgradeexisting cellular networks for the benefit of IoT. This means that patterns in energyconsumption during communication for existing versions of these standards will havethe additional benefit of being relatable to the newer versions as well. This sectionlooks, highlights and analyses work done by other that touches the subjects of appli-cation layer protocols and and how they relate to power consumption in different IoTscenarios.Shaoling[51] writes about the power consumption of CoAP on a specific board fromTexas Instruments running the Contiki operating system. Galler et. al[52] looks atthe power consumption of HTTP over GPRS.Lindberg et. al. presents a framework for comparing IoT communication protocolas well as evaluates the power consumption of IoT communication on small-rangenetworks.[53]A problematic area of IoT is the security aspect, and for this thesis, the effect it hason the communication overhead and energy consumption is highly relevant.Höglund writes about the overhead involved in securing CoAP[54]. and Tiloca mean-tions the difficulties of Denial of Service in IoT[55]. Cooper also writes about secur-ing CoAP and IoT protocols in general[56].Shared bikes is already a tested concept in certain cities around the world[57].Jiang compares the currently existent bike system in Stockholm, with the onesHangzhou[58].

2.10 Summary

Communication standards and protocols are available in abundance. The ones thathave been presented in this chapter are all intertwined in the layers of the internetprotocol suite.

FIGURE 2.1: Simplified overview of the internet protocol suite[25]

2.10. Summary 19

Each layer in the suite are designed with the design method concept of encapsulation,where all layers provide abstraction of the underlaying layers to its neighboring layerabove. This allows modularity that makes the higher layers easier to implement andindependent of underlaying layers. The Application layer protocols are the focus ofthis thesis and are the ones that will be researched in chapter 4.

20

Chapter 3

Models and Methods

To expose the true value of a thesis, it is important to abstract and model the non vitalparts of both data collection, and subsequent analysis. Below a description is givenof the development methodologies and the different modelings used.

3.1 Development Methodology

In engineering, it is key to have a methodology, to structure work. Without an agreedupon methodology there is no clear way to determine what needs to be done, whathas been done, and to assure that any progress is reproducible. In software devel-opment, these concepts are also well defined, and in the following sections the mostcommon software development methodologies and frameworks will be explained. Inthe chapter summary this thesis will present its chosen methodologies.

Agile

Agile, or Agile software development, is a set of principles where cross functionalteams collaborate with initially loosely defined requirements, to allow the solutionto a software development task to evolve as development is progressing into a prod-uct.[59]

Scrum

Scrum is agile software development framework that aims to substantialize the goalsof the agile manifesto. It states that a Scrum team, must have a Product Owner, that isknow to every team member. The Product Owner must have and maintain a ProductBacklog. The backlog size and complexity is estimated by the team, together with theProduct Owner and a Scrum master, that makes sure everything follows protocol. Theteam must know their own current velocity, i.e. the speed at which they are "burning"or working through the backlog. Each team member must be cross functional, andbe able to do every task in the backlog. A scrum project, works in time segments

3.1. Development Methodology 21

called sprints. These sprints have several obligatory group activities that must beconducted.

• Sprint Planning

• Daily Standup

• Demo

• Retrospective

Each day in a sprint is started with a daily standup, where everyone in the team tellsthe rest of the team, what they did yesterday and what they will do today. At theend of a sprint, a Demo is held. Where the team will show stakeholders and ProductOwner what results from the sprints work are. The Demo activity is usually imme-diately followed by a Retrospective activity, where the team discusses the previoussprint, and what can be done better in the next.[60]

Kanban

Kanban is another agile software development framework, it was developed at Toyotain the 1940s, inspired by the way shelves are stocked at supermarkets[61]. It focuseson describing task visualization and the concept of work pulling, where a teamscapacity is determined by the rate at which individual members can complete andpull new tasks. Since the team always aims to have just enough work to keep goingonce a task is done, it has flexible planning with a clear overview of what is to bedone. It is common to keep the visualization board simple. With columns

• To Do

• Doing

• Done

The scope of the project is always whats in the current board. Meaning that there isno backlog of tasks that are saved for once the ones in the board are finished. Insteadthe intended effect is to force all involved stakeholders and developers to carefullychoose what new tasks are created and placed in the "To Do" column. This givesa guarantee that the size and scope of the project can never become so large that itcan’t be easily overviewed.Kanban shares some concepts with Scrum, although executed differently, such with:Cadence being a continuous flow instead of strict sprint intervals. Metrics is donethrough task cycle time instead of velocity. Changes to the scope can happen at any

22 Chapter 3. Models and Methods

time as opposed to only when a sprint is done. A large difference though is thatit does not keep a backlog. There are no sprints, and as a consequence the wholedevelopment is one continuous flow. [61]

Waterfall

Waterfall is a software development process where a product is produced in sequen-tial segments, each segment done by a specialized team. The process is inspired byconveyer belt manufacturing and building construction, where the requirements isnot expected to change or regarded as costly. It has six stages of, each passing onresults to the next, and covers the entire product live-cycle.

It has historic prevalence in software development, but have in more recent years,been largely replaced by agile methodologies, due to criticism of it being too com-mon for requirements to change in software development.[62]

Lean

Lean software development(LSD) is a modern methodology where the user acceptthe fact that writing and building is a learning process itself, requiring iteration, andthat you are unlikely to know what you should build at the start of the project.Only through iteration and user feedback are you able to build the actual product.This methodology is a reaction to the experiences from many software developmentprojects where a lot of time is wasted on features that are not used.

3.2 Data Collection Methods

Data collection methods are the means by which data is collected.

• Experiments

3.3. Data Analysis Methods 23

• Questionnaires

• Case study

• Observations

• Interviews

Experiments are conducted to collect large quantities of data. Questionnaires arecollecting data through questions and surveys. Case studies is more focused smallscale study. Observations looks at behaviors in certain situations. Interviews looksat participants reactions.Data collection will be done through experiments, where different configurations ofcommunication and operation strategies are tested while the energy consumption ofthe device is measured and logged.

3.3 Data Analysis Methods

Data analysis methods are used to analyze the data collected. It is used to supportdecisions and conclusions. The most common quantitative methods are

• Statistics

• Computational mathematics

Statistics are used to calculate results and to look at significance of those results.Computational mathematics are used to find significance in data through numericalor algorithmic calculations.The most common qualitative methods are

• Coding

• Analytic induction

Coding analyses interviews and observations to allow for statistical analysis of some-thing that might otherwise be qualitative.The data from the experiments will be analyzed through statistical and computationalmathematics.

3.4 Quality Assurance

After the research is done, the produced research material needs put into scrutiny tofind errors. For quantitative research it entails determining if the results have been

24 Chapter 3. Models and Methods

reached with correct measurements and experiments, and if they are reproducible.For qualitative research it entails the same as for quantitative but also need confirma-bility to make sure that no subjectivity is affecting the results.For assurance of the quality of the data collected and analyzed. experiments will berepeated to assure reproducibility, to produce the measurements, two separate toolswill be used to guarantee that the true values are being recorded.

3.5 Summary

This thesis will use a Kanban board for visualizing and tracking progress in the thesoftware development work done. In the next chapter a survey research strategy willbe used by comparing the results from different experiments.

25

Chapter 4

Platform Prototype for PubliclyShared City Bikes

This chapter covers the implementation of a platform prototype for a publicly sharedcity bikes project. This is done to give a context for the scenarios used in the survey,and to provide a foundation for the protocol found to be most suitable to be applied.The prototype allows a predefined user to approach a bike, unlock it to start renting,proceed to use it, and then lock it again and thus end the rental. The bike acts asdumb node, that only relays the attempt to unlock and lock the bike to anothersystem where the authentication and other business specific logic resides, and thissystem decides if the bike should unlock or lock itself. At all time, the bikes alsorelays its current position to the other systems at fixed intervals, but since it is likelythat it is stationary while unrented, it relays the position less frequently then.

The chapter ends with a summary of the resulting platform.

4.1 Platform

The platform prototype is made up of several subsystems connected to each other.First there is the embedded device, acting as the mobile node attached to the bike.This device is communicating with a so called broker, which acts as a two way queuefor inbound and outbound messages. This broker is also responsible for keepingtrack of connected devices, so that it knows where to send messages when it needsto communicate with a specific node. The broker is in turn connected to the coresystem, that stores all registered devices and users in a database. This is whereusers and nodes are correlated, i.e. where all the platforms business logic resides.Whenever a user or bike node produces an action through the platform, it is the coresystem that in the end allows or disallows it to have consequences.

FIGURE 4.1: Platform Overview

26 Chapter 4. Platform Prototype for Publicly Shared City Bikes

There are an arbitrary amount of nodes communicating through cellular networks toa virtually single broker in the cloud. The broker then parses and passes messages onto the protocol agnostic core system.

4.1.1 Embedded device

The embedded device acting as the network node for the bike, is the platform subsys-tem that will dictate the means of communication. This because it will be the mostconstrained part of the platform, since the broker and core will reside in the cloudand does not need to care about efficiency to the same extent.Since it is outside the scope of this thesis, it’s interfacing towards the user is leftout. But it can be theorized that it has means of letting the user identify itself whenadjacent to the bike, and subsequently unlock the bikes lock, releasing temporaryownership to the user.In order for the connected bikes to be tracked and maintained, the nodes commu-nication needs to be correlated with spatial-temporal marks. The administrators ofthe platform needs to know when and from where a bike for example reported that ithad an error, for it to be possible to send out a technician to repair it. This requiresa GPS to be used. The position from the GPS will be queried at fixed interval andcommunicated to broker. The most important part, the communication itself, will beas described in previous chapters, done through GPRS for the prototype.The communication between the bike node and broker can be described as such.

FIGURE 4.2: Device Broker Sequence

4.1. Platform 27

The diagram covers the messages required to be implemented for the prototype. Thebike node needs to be able to communicate a users authentication attempt and thenreceive either a successful of unsuccessful indicating response. It also needs to beable to report its system status as well as position.The embedded system chosen to implement the embedded device is the Atmel SAM-D21, which is a ARM-Cortex M0+ micro-controller. It is chosen for its energy ef-ficiency and it extensive peripherals, such as hardware support for the bus-protocolsneeded to communicate with thee GPRS and GPS modules.The device will from a energy consumption viewpoint have two states or modes,active and passive. During active mode the energy consumption will be high in com-parison to when it is in passive mode. Active mode is where it performs any tasksuch as interacting with a user, performing measurements, or communicating withthe broker. The passive mode is where it is practically dormant.From a activity and user viewpoint it will either be idle, or it will rented. The changesbetween activities of the embedded device will for the prototype be the following

FIGURE 4.3: Embedded Device Activity


During it is in idle state, the device is mostly passive, only requiring it to be activeto communicate with the broker at a infrequent interval to report its spatial-temporalstatus, and to detect unlock attempts from users. When it is in the rented state, itwill do the same reporting, but at a higher frequency. Between these states is theunlocking and locking of the bike which is also requires it to be active. It is the goalof a embedded device to be in passive mode as much as possible since it saves energy.

4.1.2 Broker

The broker is the glue of the platform, and is what ties the business logic of thecore system containing the users, together with the bike nodes. Since it’s crucial thatthe broker is always accessible to the nodes. It needs to be using a framework thatpromotes design patterns with fault tolerance and high uptime in mind.Because of the requirement of high uptime and the possibility to reuse the structureand protocol parser from what was implemented in 5 chapter. The broker was chosento be implemented in the Elixir language, that with its access to Erlang and OTPmakes it a proven concept for fault tolerant systems.In Elixir, by extension of the OTP design principles, application processes are builtas individual services, divided up into supervisors and workers in a so called su-pervision tree. Workers are the processes that perform the actual work. And thesupervisors monitor the workers and have the ability to restart a worker if somethinggoes wrong. Since the supervision tree is hierarchical this allows the design of faulttolerant Applications. For the broker the supervision tree looks as following

FIGURE 4.4: Broker Supervision Tree

The different workers are all representing some kind of message parsing with con-nection to a message queue from which they pull more work from. All the different

4.1. Platform 29

workers can put messages on the other ones queues.The queues are implemented with RabbitMQ[63], an open source message brokerwhich can act as a queue allowing producer and consumers to push and pull messagesfrom it. All interaction with queues are logged, allowing traceability and predictablestate changes on the broker. RabbitMQ also has the benefit of persistent storage.meaning that messages are synchronized from volatile memory to hard-drive mem-ory allowing them to resume from the stored state in case of a server crash or beingrestarted by a supervisor reducing any chance of messages being lost and reducingstartup time.

Inbound Node Worker

Pull messages from the inbound bike node queue, and parses them into a intermediatedata representation specific for the broker platform. It then pushes the data to theoutbound core queue.

Outbound Node Worker

Pulls messages from the outbound bike node queue, translates from the brokers in-termediate data representation into the protocol used to communicate with the bikeand sends the message to the target bike node.

Inbound Core Worker

Pulls messages from the inbound core queue, All communication between the brokerand core is done through HTTP, so the pulled message will be a HTTP request. ThisHTTP request is translated into the broker intermediate data format and pushed tothe outbound node queue.

Outbound Core Worker

Pulls messages from the outbound core queue. This message is usually a intermediaterepresentation of a message received from a bike node. The message is sent to thecore system using HTTP.

4.1.3 Core

The core system is the business logic layer of the platform prototype. Its purpose isto store data about bike nodes and users in two data separate databases, and allowdifferent actions to be applied to these data structures. All of these actions adhere topredefined rules representing the so called business logic, such as making sure a user


has payed before it can unlock a bike, or that a bike is not in use when an attempt torent it is made.

Its configuration of nodes is done through an administrator interface where bikenodes can be added or removed. New bike nodes receive a unique identifier thatcorresponds to a value that is programmed into the embedded device when it’s man-ufactured, this value is sent along with communication received from the broker, tothe core, so it can find the representation of the node in the database.Users are for the platform prototype also managed through an administrator inter-face. It is outside the scope of this thesis to look at a customer interface where newusers can register and pay without administrator supervision.The core is on purpose abstracted away from the physical world of the embeddeddevice nodes. Its only interaction is with the broker.

FIGURE 4.5: Broker Core Sequence

The reason for this abstraction is to allow the core to remain protocol agnostic incase either the broker is replaced with a commercial solution or the communicationbetween the broker and embedded devices changes. It also serves the purpose of al-lowing the replacement of the core system itself, as there are today numerous similarservices provided from multiple companies that would provide several advantages toa self implementation. Currently the most viable competitors are

• Microsoft Azure IoT Hub[64]

• Google Cloud IoT Core[65]

• Amazon IoT[66]

4.2. Summary 31

All of which provide the same services as the thesis suggested core while at the sametime allowing integration with all of the cloud service providers other services. It washowever determined that it was outside of the scope to implement this integration.

4.2 Summary

The described platform consists of three subsystems, all of which are designed toprovide abstraction and the possibility of being switched out with only minor changesto the other subsystems. While there are numerous applicable commercial solutionsfor both the broker and core system it was determined that a self implementation wassufficient for a prototype. The platform description will be completed as the node tobroker communication is selected and described in chapter 7.

32

Chapter 5

IoT Communication Protocol Survey

This chapter presents a experimental survey of application layer protocols tested onGPRS modules, to determine their viability to be used by mobile mid-range IoTdevices, while also providing a starting point once the newer standards are imple-mented and available for commercial use. It starts by an in depth accounting of theimplementation method and development of the protocol survey, as well as its exe-cution. It continues with the a explanation of the models and measurements used toextract value from the survey. This is followed by the presentation of the protocolsfocused by the survey how exactly the are to be compared and what delimitationsthis comparison might have.

5.1 Survey Implementation

To perform the survey, required the development of a implementation of the proto-cols, along with a test platform on which to execute the tests and at the same timemeasure the voltage and current to determine the energy consumption accuratelyduring a transmission sequence. The development method used to achieve this wasKanban. This was chosen since the thesis work was done by a single developer, andthus all the different roles for Scrum not possible to fill. It would also have been re-dundant to work in locked sprints, since there was no real stakeholder to present theprogress to, and no risk of features being added after planning, and the real metric ofprogress would be the speed of the single developers task pulling capability anyways,aligning well with Kanban.The Kanban board containing tasks maintained throughout the process, was done us-ing the project management tool Trello[67]. Trello is a free to use general purposeproject management that offers a un-opinionated and customizable digital Post-it sur-face, and can be used to overview any methodologies progression. The first step wasto to gather all project requirements and from these produce a initial listing with allthe individual high level task in the backlog or "To do" column. These task wascreated because once they were finished, some initial testing could be performed.

5.1. Survey Implementation 33

TABLE 5.1: Kanban board, after first requirement gathering.

To Do Doing Done

Implement MQTTpacket builder

Implement CoAPpacket builder

Implement HTTPpacket builder

Implement AT com-mand interface

Implement protocollogger

After this, the tasks was one by one moved from "To Do" to "Doing" and finally to"Done", sequentially as they were started and finished. The moving of a task fromthe "To Do" column represents Kanbans concept of work pulling, and the mean rateof which this is done is coincidentally also the metric of progression since there isonly a single developer.

TABLE 5.2: Kanban board, after 160 hours of development.

To Do Doing Done






After 160 hours of development most of the larger tasks was completed. These taskwas chosen to be developed first, because they allowed a initial test of the survey tobe performed, to see that there was merit to the chosen solution and that the workshould continue based on the initial approach.Following this more tasks were created and added to the board to finalize the work.

34 Chapter 5. IoT Communication Protocol Survey

TABLE 5.3: Kanban board, after second requirements gathering

To Do Doing Done






Host protocol logger incloud

Build framework fordata graphs

Build amplified shuntmonitor

Implement sample log-ger

Implement sample lowpass filter

Implement power inte-gration tool

Implement sample se-quence alignment tool

This turned out to be all the different tasks needed to perform the survey and it tookabout 120 hours to complete for a total of 280 hours of development. This makes themean velocity 280/13 ≈ 22 hours per task.

5.1.1 Implementation Validation

While there does not exits any reference implementation for any of the protocolspecfications, it should be noted that this thesis implementations was validated byeither being used together with or compared with a recommended implementation.The MQTT implementation was used with the Mosquito MQTT broker[68]. TheCoAP implementation was used with a popular Erlang CoAP server[69] and also

5.2. Measurement 35

compared with the recommended Copper (Cu) plugin[70]. The HTTP implementa-tion was used with the Phoenix framework HTTP server[71].

5.2 Measurement

Power consumption is logged through measuring the voltage drop across a shuntresistor that is connected in series with the GSM/GPRS module. The voltage dropis amplified and refined through a current shunt monitor INA168 and then measuredthrough a ADC with 12-bit resolution on a Atmel SAM-D21 micro-controller with asample rate of 1 kHz.

FIGURE 5.1: Circuit for the experiments measurement platform

The voltage output Vo from the INA168 can then be measured to calculate the currentIs running through the resistor Rs through the formula

Vo = (Is∗Rs∗Rl)/5000

Where Vo is the voltage across the Rs resistor, the formula can be simplified to ex-press the sought current by

Is = (Vo∗5000)/(Rs∗Rl)

The INA168s voltage output Vo is related through Ohms law to the current Is. Sincethe resistances Rs and Rls values was chosen to be Rs = 0.1Ω and Rl = 50kΩ. Therelation can be simplified as Is =Vo/1Ω

The power consumption Joule(J) is derived through the voltage drop and currentacross the module over time as such: The watt (P) relation with voltage(U) and


current(I)P =U ∗ I

The relation of power over time(Wh) relation with Joule(J)

1Wh = 3600J

Which means that we can express the consumed energy in joules as

J = 3600∗∫ t

0I(t)∗U(t)dt

5.3 Application layer protocol

The target application layer protocols of this survey, will be CoAP, MQTT, andHTTP. CoAP, because of it being designed for constrained environments. MQTTis a older protocol than CoAP, but likewise as marketed towards IoT applications.HTTP is not a protocol intended specifically to be used in IoT, but is more of a gen-eral purpose protocol, with an emphasis on being simple. It regarded as the glue ofthe Web, and is a natural baseline to compare any IoT originated solution.The survey opted not to test DDS due to time constraints. Protobuf was disregardeddue to the fact that it is less of a communication protocol and more of a data format.Even though it shares this encapsulated approach with little opinion of underlayingnetwork layers with CoAP. It still appears more comparable with serialization proto-cols such as Java Script Object Notation(JSON).

5.4 Transport layer protocol

The different communication protocols are all implemented on a application level.They assume different transport layers to achieve their intended quality of servicelevels.

TABLE 5.4: Protocol Transports

Protocol Transport

CoAP UDP

MQTT TCP

HTTP TCP

5.5. GSM/GPRS Modules 37

5.5 GSM/GPRS Modules

Two of the markets currently most popular GSM/GPRS modules marketed for M2M,were selected to provide a comparison and to be able to rule out any module spe-cific deviations. To do this the modems SIMCom SIM800L[72] and ElectrodragonA6[73] are selected, as they represent the currently most available low price sectionof the market. The speed of the modems is dependent on how many time slots itis able to allocate times the bit transfer speed of upload or download. For upload21.4∗ timeslots kbps. For download: 85.6∗ timeslots kbps.

TABLE 5.5: GPRS modules uplink and downlink specifications

Modem uplink TS downlink TS upload speed download speed

SIM800L 2 4 42.8kbps 342.4kbps

A6 4 4 85.6kbps 342.4kbps

5.6 Protocol State-fulness

While UDP is inherently stateless, packet are sent and no guarantees are given, TCPis an active connection with several features such as error correction and flow con-trol. Both MQTT and HTTP rely on these features to deliver requests and receiveresponse, but since MQTT requires the transmission of multiple packets over a sin-gle connection for most of it’s requests it can be seen as stateful. This will addoverhead to any MQTT request when there is not a previously set up connection.

5.7 Packet Logger

A simple packet Logger was set up to receive and log all UDP and TCP trafficsent to it on a cloud hosting service. This was used as the target server for all theexperiments to detect inconsistencies in transmitted and received packets, and tomock HTTP and MQTT responses.

5.8 Survey Delimitations

The survey will not cover all factors that would affect power consumption directly orindirectly in a real world application using one of the protocols in question. It willnot look use any security measurement, such as encryption through TLS, or DTLS.While both MQTT and CoAP are marketed towards IoT environments, they still


have different typical use cases. MQTT is the most efficient when it can maintainand reuse a single connection over and extended period. This reduces it the overheadof setting up the connection and also allows the MQTT broker server to have pub-lished data pushed to the MQTT node if it has subscribed to the topic in question.Similar interaction for CoAP would require it to use the observe feature[74], whichis standardized, but remains a best effort approach.

5.9 IoT communication experiments

IoT applications are divided into sensors or actuators. To test the power consumptionof the different protocols, typical IoT scenarios for sensors and actuators are simu-lated while measured. The small packet test simulates a embedded sensor sendingmeasured temperature data on a large interval. A larger interval would make the de-fault strategy to close connection between the active periods where it is transmitting.The large packet test simulates a similar sensor as the first test, however in this test,instead of a small temperature value, the payload is a large array of binary data, e.g.a image or a more complex data structure. The multiple small packets simulates aembedded sensor sending small packets of binary data on a small interval. A smallinterval makes the strategy to not close the connection between transmissions, andshould benefit the protocols that use TCP as transport. The different tests will featuredifferent payloads. Since the protocols allow for any type of content to be transferred,the most common serialized data format of the web, JSON was chosen to emulatetypical usage, as well as a simple un-opinionated sequence of binary data. All theprotocols produced binary sequences for the different tests can be found in appendixA.

Small Packet Test

Posting or publishing packet to endpoint "/data". Payload: Temperature data in aJSON object with one field: "value": 24, with a length of 13 bytes.

TABLE 5.6: Small Packet Payload

Protocol Packets size (Bytes)

CoAP POST 31

MQTT CONNECT + PUBLISH + DISCONNECT 22 + 31 + 2

HTTP POST 137

5.9. IoT communication experiments 39

Large Packet Test

Posting or publishing packet to endpoint "/data". Payload: Large sequence of binarydata with a length of 100 bytes.

TABLE 5.7: Large Packet Payload


CoAP POST 111

MQTT CONNECT + PUBLISH + DISCONENCT 22 + 111 + 2

HTTP POST 218

Multiple Small Packets Test

Repeatadely posting or publishing packets to endpoint "/data". Payload: Small bi-nary value with a length 1 byte.

TABLE 5.8: Multiple Small Packets Payload


CoAP POST x10 12 x10

MQTT CONNECT + PUBLISH x10 + DISCONNECT 22 + 12 x10 + 2

HTTP POST x10 117 x10

40

Chapter 6

Communication Protocol EnergyConsumption Comparison

This chapter contains the resulting measurements from the test scenarios presentedin the previous chapter. Each result is presented as a graph and a table with themeasured values for the two modules, this is then followed by a evaluation of thevalues. The chapter ends with a summarizing evaluation.

The measured samples presented in the graphs have been passed through a movingaverage low pass filter. Due to the combination of the previously mentionedlow sample rate for measurements and nature of GSM/GPRS modules frequentlyswitching antenna activity. The moving average window was set to 100 samples.This makes the overall energy profile of the protocol visible but it also hides some ofthe more intricate characteristics of the GSM/GPRS time-slots, as well as requestsfollowed by responses dynamics for TCP. The values in the presented tables areextracted from the raw values that has not passed through the filter. However, forboth the passive energy consumption offset has been subtracted to only get therelative active power consumption.

Before the measurements were performed, the signal quality and strength waschecked. For all measurements, the Received Signal Strength Indication (RSSI) wasreported to be around -51 dBm, and the Bit Error Rate (BER) was reported to be lessthan 0.1%.

6.1. Small Packet Test Results 41

6.1 Small Packet Test Results

A6

TABLE 6.1: Data from small packet test run on A6

Protocol CoAP MQTT HTTP

Transmission duration (ms) 4000 6000 5000

Average power during transmission (W) 0.19 0.2 0.2

Integrated energy consumption (J) 0.37 0.46 0.52

FIGURE 6.1: Transmission sequence from small packet test run onA6

42 Chapter 6. Communication Protocol Energy Consumption Comparison

SIM800L

TABLE 6.2: Data from small packet test run on SIM800L





FIGURE 6.2: Transmission sequence from small packet test run onSIM800L

6.1.1 Small Packet Test Evaluation

For this scenario the transmission duration almost equal for the different protocols.CoAP has a similar average power usage during transmission, but due to its lowerduration, has a lower power consumption than the others. This is likely due to un-derlying transport UDP, which means that it does not confirm that the sent data hasbeen received. The low pass filter applied to the samples, makes MQTT appears ashaving a lower peak power usage, but in reality it is more likely that this is due to ithaving lower power usage between its different packets being sent. This is supportedby the fact that the integrated power consumption is lower than the one for HTTP.

6.2. Large Packet Test Results 43

6.2 Large Packet Test Results

A6

TABLE 6.3: Data from large packet test run on A6





FIGURE 6.3: Transmission sequence from large packet test run on A6


SIM800L

TABLE 6.4: Data from large packet test run on SIM800L





FIGURE 6.4: Transmission sequence from large packet test run onSIM800L

6.2.1 Large Packet Test Evaluation

It can be observed that the overhead has less benefit with the larger payload. MQTTthat has to transfer three packets, has a larger power consumption than its TCP base-line HTTP, which only sends one. This suggests that while the overhead is smaller onindividual MQTT packets, and the transmitted data in total is smaller than for HTTP,sending these three is less efficient.

6.3. Multiple Small Packets Test 45

6.3 Multiple Small Packets Test

A6

TABLE 6.5: Data from multiple small packets test run on A6





FIGURE 6.5: Transmission sequence from multiple small packets testrun on A6


SIM800L

TABLE 6.6: Data from multiple small packets test run on SIM800L





FIGURE 6.6: Transmission sequence from multiple small packets testrun on SIM800L

6.3.1 Multiple Small Packets Test Evaluation

It can be observed that the lower overhead makes both CoAP and MQTT efficientrelative to HTTP. It can also be observed that CoAP is seeing diminishing return fromusing UDP rather than TCP, as the MQTT is more efficient compared to it’s overheadseen in the large packet test.

6.4. Summary 47

6.4 Summary

The test was performed on two completely different platforms to highlight anyanomaly specific to a platform. And in the tests there was a pattern of differencesbetween the two platforms used. It was expected that the A6 module would benefitthe protocols relying on TCP for transport, since it had a faster uplink. This becausethey are actually waiting for the target host to respond with acknowledgementsfor the packets sent. And since the CoAP requests had somewhat similar durationit could be assumed that this was the common denominator for the difference.However the test showed a larger difference between the two platforms than thisfactor can account for. It is probably a contributing factor, but it is more likely thatthe SIM800L has a inferior TCP implementation, skewing the results.

48

Chapter 7

Communication Protocol for PubliclyShared City Bikes

This chapter presents how previous chapters survey results are applied to theselection process for the communication protocol used between the node and brokercomponents in the described platform prototype. It the shows how the protocol isapplied.

For the communication between the bike nodes and the broker, the protocol CoAP isused. It was selected based on the proved transfer speed and low energy consumptionit displayed in the pervious chapters survey. Though most commercially availablebrokers today use MQTT it was determined that the energy consumption overheadit introduces makes it unsuitable for embedded IoT devices. There was also severalnoted exceptions in the MQTT specification that made the implementation inferiorcompared to CoAP.

• No standardized error handling, in addition to the suggested strategy for anyerrors or inconsistency being to close connection, which contradicts Postel’srobustness principle[75] for how communication over the internet should beregarded, which states that one should "be liberal in what you accept fromothers".

• No support for meta-data, such as content-type, forcing the implementationof a non-standardized meta-data within the payload. This also promotes thedesign of close systems, not open to new actors joining the network, contra-dicting IoT principle of device interoperability since they can’t be sure whatprotocol the payload is defined with[32].

These are all core principles of the World Wide Web(WWW) that HTTP follows andthat CoAP also mimics, which makes it a logical choice for an IoT platform.With CoAP the platforms communication will consist of the following requests fromthe embedded devices and the brokers responses.

Chapter 7. Communication Protocol for Publicly Shared City Bikes 49

Unlock

The unlock request is done whenever a user tries to unlock the bike node, It is aimportant request, that need the quality of service assurance of only being done once,and the node needs to wait for a response from the core through the broker to knowif it was successful.

FIGURE 7.1: CoAP unlock Request

The request is done through a confirmable(CON) POST request with a payload of theusers identification and the bike nodes unique identifier. Confirmable indicates thatthe receives has to acknowledge the request, if no acknowledge response is received,the request will be repeated. The response is a simple "yes" or "no" to whether itshould unlock and is included or what is often called piggybacked with the acknowl-edge request.

Lock

The lock request is similar to the unlock request.

FIGURE 7.2: CoAP lock Request

It also needs to wait for acknowledgment from the broker, the intended behavior ofthe platform is that a user can’t lock a bike, or in effect end a rental unless someprerequisite rules are fulfilled and are enforced by the core system.

50 Chapter 7. Communication Protocol for Publicly Shared City Bikes

Report

The report request is performed at a set frequent interval once the bike is unlocked,and on a more infrequent interval when unlocked. It reports the spatial-temporalstatus of the bike node.

FIGURE 7.3: CoAP report Request

It is done through a non-confirmable(NON) POST request, and does not need to beacknowledged by the broker. This design is chosen since it’s does not have severeconsequences if a report does not reach the broker, as long as most of them do. Thissaves energy since the node does not need to wait for response and can immediatelyafter send go back to passive mode.

51

Chapter 8

Conclusions

This thesis covers the search for a application layer communication protocol that isapplicable in high latency energy efficient embedded mid-range IoT devices. It startsby describing a platform prototype for publicly shared bikes, to give a context for thesurvey and to further present the background of the problem. Then the thesis surveysthe field of protocols that are either popular in general or marketed for IoT, supportedby the literature study presented in the background. It reaches the decision to test theprotocols HTTP, MQTT and CoAP by experiments which quantifies the impact theyhave on energy consumption during transmission.After the survey results are presented, the learnings are applied to the described plat-form for shared bikes to solve the problem of which application layer communicationprotocol should be used.The following sections contains an account of this thesis findings and how it wasachieved. This is followed by the results and its place among the related work. Itends with suggestions for future work.

8.1 Protocol Survey

The protocol survey is conducted to measure the impact on energy consumption thatdifferent application layer communication protocols have when used through cellularnetworks. The purpose of the survey is to identify a protocol that is more applicablethan the others in a project to build a platform prototype for the shared bikes.It required the development of a implementation of the current specification for eachof the protocols HTTP, MQTT and CoAP. These implementation filled two purposes,first it gave insight and deeper knowledge of the individual protocols. And secondlyit allowed the direct integration with the test platform, which is needed since the pro-tocols needed to be used through GSM AT commands over a serial connection.It can be argued that a better comparison could be made if more modems was usedin the tests, since there appears to be a large difference of implementations. Whetherthat difference is due to difference in the network, link or transport layer, is difficult

52 Chapter 8. Conclusions

to determine and is not in the scope of this thesis.The survey finds that there is a significant difference in the energy consumption be-tween the protocols performing the same tasks, and consistently it shows that themost energy efficient in any scenario is CoAP. A noticeable difference in payloadsize is highlighted already in the survey description chapter 5 where the total CoAPpayload was around a third of HTTP and around half of MQTT for the single packetscenarios. But in the multi-packet scenarios this difference between MQTT andCoAP became less of a factor to the point of being dismissible. Though even inthese multi-packet test CoAP outperformed the other protocols, and likely attributedto the fact that CoAP uses UDP for transport, which seems to be more efficient thanTCP in this environment of embedded devices using GPRS for communication.In the context of embedded mobile devices, with the purpose of being applied toa platform for shared bikes, the evidence suggest that the most suitable protocol isCoAP.It should be noted that for any networks that is open such as the internet, there needsto be a security layer added. This would add overhead to any protocol, but wouldlikely affect the comparison between MQTT and CoAP, as it would penalize CoAPmore that MQTT due to their respective transport layer protocols.The survey results display some unexpected patterns for transmissions on one of theGRPS modules. As discussed in chapter 6, it is likely due a specific problem withthe TCP implementation on that module. This highlight a weakness in the survey,in that it does not cover a large enough sample size for it to be possible to rule thisinconsistency out as a deviation from the norm. Though it can be concluded thatthe unexpected inefficiency does not affect the UDP based CoAP protocol, whichconsistently displays a similar transmission pattern.

8.2 Platform Prototype

The platform prototype shows and highlights the intended application of thecommunication protocols tested in the survey. Based on the decision of preferredprotocol, it proceeds to describe how the communication semantics is designed withCoAP. For the requirements of the prototype, CoAP fits well with the a describedarchitecture, which promotes decomposability where the platform is divided intothree subsystems: The embedded device nodes, which represent the bikes, and areusing CoAP over a cellular network connection to communicate with a messagebroker. The message broker translates messages from CoAP to a less constrainedprotocol such as HTTP to communicate with the the core system. The core systemis the protocol agnostic logic and rule enforcer, where business logic is applied to

8.3. Comparison with related work 53

the actions of users and bike nodes. There are multiple reason for keeping the coresystem separate from the broker even though they are both residing in the cloudand possibly even on the same server. First for the reason of having the possibilityto replace either the message broker or the core system with one of the manycommercial solutions available when moving from the prototype stage. Secondly forthe reason of fault tolerance. Both the broker and core are implemented with thesein mind, and following patterns for separation of concerns makes it logical to keepthe separate. As an additional gain from using CoAP is that its specification is donewith a one to one mapping to HTTP in mind to make the implementations of CoAPto HTTP and in extension the Internet easy[76].

8.3 Comparison with related work

There have been work done before this thesis that evaluate the subjects of both ap-plication layer protocols, the transport layers, and the underlaying communicationtechnologies. What this thesis uniquely provides, is a comparison between differentprotocols marketed specifically for IoT, while also providing a well known baselineprotocol. It also provides a evaluation of what operation quality of some popularGSM/GPRS modules.As mentioned in the related work section in 2 there exist already similar solutions toshared bikes platforms to the one described in this thesis. A niche area not yet ex-plored is a collaborative solution instead of a commercial one. The market is alreadyfilled with solutions centralized around the idea of a smart-phone app distributed bya single company which gives access to that companies provided bikes. With thewidespread digitalization and acceptance of collaborative efforts seen in some cities.A solution could instead be a decentralized distributed network, where any user orbike can join simply by appending a device to their already owned bikes, under theagreement that the user get access to other users bikes, and they to its.The described platform prototype could be adapted to try out a concept such as this,with its focus on energy efficiency, bike nodes would have a long period of operation,making it suitable for a small city or group of people that would initially be usingbikes infrequently.

54 Chapter 8. Conclusions

8.4 Future Work

An improvement to the experiments would be to be able to have a instruments thatcould measure at a higher frequency than the 1 kHz this thesis used, while still main-taining the same memory depth to capture the whole transmission sequence. Thishigher samples rate would likely allow a more in depth analysis where you couldrelate the different transport protocols efficiency to the GPRS modules uplink anddownlink time-slots.The protocols evaluated in this thesis, are as any other technology evolving constantlywith new versions published at steady intervals. For established protocols as thosethe changes are usually backwards compatible, and can as thus be expected to onlyhave nominal effect on their performance. HTTP however is soon to have a successorcalled HTTP2[77] which will co-exist with HTTP but does offer functionality suchas header compression that would likely be beneficial in the experiment this thesisconducted.A IoT device that is connected on a shared network, such as the Internet needs tohave a security functionality, preventing malicious reading or tampering of the databeing sent. For most communication on the internet, this entails the addition ofcryptographic protocol TLS for TCP, and DTLS for UDP transports to provide thesecurity, allowing the application layer protocol to remain independent. These proto-cols does add significant overhead[39][38]. Not only in the amount of data sent butit also affects the operation of the transport protocols in such a way that it would beinteresting to perform the experiments with these features added. Finally, a way tosettle the ambiguity between TCP and UDP, is once the mentioned CoAP over TCPspecification is accepted, try the same tests with the two different versions of CoAP.

55

Bibliography

[1] ITU. Internet of Things Global Standards Initiative. 1999. URL: http://www.itu.int/en/ITU-T/gsi/iot/Pages/default.aspx (visited on09/30/2010).

[2] Carnegie Mellon University. The Only Coke Machine on the Internet. 1982.URL: https://www.cs.cmu.edu/~coke/history_long.txt (visited on12/08/2016).

[3] Gateway Technology Labs. Internet of Things. 2017. URL: http://www.gatewaytechnolabs.co.uk/internet-things (visited on 04/20/2017).

[4] Ericsson. Ericsson Mobility Report June 2015. 1999. URL: http://www.ericsson.com/res/docs/2015/ericsson-mobility-report-june-

2015.pdf (visited on 09/30/2010).

[5] Cisco. IP Version 4 and IP Version 6. 1999. URL: http://www.ciscopress.com / articles / article . asp ? p = 348253 & seqNum = 7 (visited on09/30/2010).

[6] Intel. 50 Years of Moores Law. 2017. URL: http : / / www . intel . com /content/www/us/en/silicon-innovations/moores-law-technology.

html (visited on 05/12/2017).

[7] Mouser Barry Manz. Standardizing IoT Connectivity by the Kilometer:

SIGFOX, LoRA R©, or LTE? 2016. URL: http : / / www . mouser . se /

applications/sigfox-lora-lte/ (visited on 02/21/2017).

[8] 3GPP. 3rd Generation Partnership Project. Technical Specifications 36:104,

release 13. 2015.

[9] Ericsson. 5G for the Networked Society. 1999. URL: https : / / www .

ericsson.com/5g (visited on 09/30/2010).

[10] GSMA. Extended Coverage – GSM – Internet of Things (EC-GSM-IoT ).2017. URL: http://www.gsma.com/iot/extended- coverage- gsm-internet-of-things-ec-gsm-iot/ (visited on 05/27/2017).

http://www.itu.int/en/ITU-T/gsi/iot/Pages/default.aspx

http://www.itu.int/en/ITU-T/gsi/iot/Pages/default.aspx

https://www.cs.cmu.edu/~coke/history_long.txt

http://www.gatewaytechnolabs.co.uk/internet-things

http://www.gatewaytechnolabs.co.uk/internet-things

http://www.ericsson.com/res/docs/2015/ericsson-mobility-report-june-2015.pdf



http://www.ciscopress.com/articles/article.asp?p=348253&seqNum=7

http://www.ciscopress.com/articles/article.asp?p=348253&seqNum=7

http://www.intel.com/content/www/us/en/silicon-innovations/moores-law-technology.html



http://www.mouser.se/applications/sigfox-lora-lte/

http://www.mouser.se/applications/sigfox-lora-lte/

https://www.ericsson.com/5g

https://www.ericsson.com/5g

http://www.gsma.com/iot/extended-coverage-gsm-internet-of-things-ec-gsm-iot/

http://www.gsma.com/iot/extended-coverage-gsm-internet-of-things-ec-gsm-iot/

56 BIBLIOGRAPHY

[11] Anne Håkansson. Portal of Research Methods and Methodologies for Re-

search Projects and Degree Projects. Athens. Athens, United States: TheSteering Committee of The World Congress in Computer Science, ComputerEngineering and Applied Computing (WorldComp), 2013.

[12] Gartner. Gartners hype cycle for 2016. 1999. URL: http://www.gartner.com/newsroom/id/3412017 (visited on 09/30/2010).

[13] ISO. Information processing systems — Open Systems Interconnection — Ba-

sic Reference Model — Part 4: Management framework. 1989. URL: https://www.iso.org/obp/ui/#iso:std:iso-iec:7498:-4:ed-1:v1:en

(visited on 02/13/2017).

[14] Guowang Miao; Jens Zander; Ki Won Sung; Ben Slimane. Fundamentals of

Mobile Data Networks. 2016.

[15] 4G Americas. GSM: Global System for Mobile Communications. 2014. URL:https : / / web . archive . org / web / 20140208025938 / http : / / www .

4gamericas.org/index.cfm?fuseaction=page&sectionid=242.

[16] Mobile Society. GPRS and EDGE Multislot Classes. 2007. URL: http://mobilesociety.typepad.com/mobile_life/2007/04/gprs_and_edge_

m.html (visited on 05/27/2017).

[17] 3GPP. GPRS and EDGE. 2017. URL: http : / / www . 3gpp . org /

technologies / keywords - acronyms / 102 - gprs - edge (visited on05/27/2017).

[18] 3GPP. Release 15. 2017. URL: http://www.3gpp.org/release-15 (visitedon 05/27/2017).

[19] GSMA. The Mobile Economy 2017. 2017. URL: http://www.gsma.com/mobileeconomy/ (visited on 05/31/2017).

[20] Lora Alliance. Lora Alliance Technology. 2017. URL: https://www.lora-alliance.org/What-Is-LoRa/Technology (visited on 05/27/2017).

[21] Sigfox. Sigfox Technology Overview. 2017. URL: https://www.sigfox.com/en/sigfox-iot-technology-overview (visited on 05/27/2017).

[22] GSMA. Narrow Band – Internet of Things (NB-IoT). 2016. URL: https://www.gsma.com/iot/narrow- band- internet- of- things- nb- iot/

(visited on 05/27/2017).

http://www.gartner.com/newsroom/id/3412017

http://www.gartner.com/newsroom/id/3412017

https://www.iso.org/obp/ui/#iso:std:iso-iec:7498:-4:ed-1:v1:en

https://www.iso.org/obp/ui/#iso:std:iso-iec:7498:-4:ed-1:v1:en

https://web.archive.org/web/20140208025938/http://www.4gamericas.org/index.cfm?fuseaction=page&sectionid=242

https://web.archive.org/web/20140208025938/http://www.4gamericas.org/index.cfm?fuseaction=page&sectionid=242

http://mobilesociety.typepad.com/mobile_life/2007/04/gprs_and_edge_m.html



http://www.3gpp.org/technologies/keywords-acronyms/102-gprs-edge

http://www.3gpp.org/technologies/keywords-acronyms/102-gprs-edge

http://www.3gpp.org/release-15

http://www.gsma.com/mobileeconomy/

http://www.gsma.com/mobileeconomy/

https://www.lora-alliance.org/What-Is-LoRa/Technology

https://www.lora-alliance.org/What-Is-LoRa/Technology

https://www.sigfox.com/en/sigfox-iot-technology-overview

https://www.sigfox.com/en/sigfox-iot-technology-overview

https://www.gsma.com/iot/narrow-band-internet-of-things-nb-iot/

https://www.gsma.com/iot/narrow-band-internet-of-things-nb-iot/

BIBLIOGRAPHY 57

[23] LightReading. Year of NB-IoT: Huawei Plans 30 Networks Worldwide. 2017.URL: http : / / www . lightreading . com / huawei - mobile - world -

congress/year-of-nb-iot-huawei-plans-30-networks-worldwide/

d/d-id/730661 (visited on 05/27/2017).

[24] Oracle. Introducing the Internet Protocol Suite. 2010. URL: https://docs.oracle.com/cd/E19455-01/806-0916/6ja85398m/index.html (visitedon 05/27/2017).

[25] Microsoft. The OSI Model’s Seven Layers Defined and Functions Explained.2017. URL: https://support.microsoft.com/en-us/help/103884/the - osi - model - s - seven - layers - defined - and - functions -

explained (visited on 05/27/2017).

[26] IETF. TRANSMISSION CONTROL PROTOCOL. 1981. URL: https : / /

tools.ietf.org/html/rfc793 (visited on 05/27/2017).

[27] IETF. User Datagram Protocol. 1980. URL: https://www.ietf.org/rfc/rfc768.txt (visited on 05/27/2017).

[28] IETF. Extensible Messaging and Presence Protocol (XMPP): Core. 2011.URL: https://tools.ietf.org/html/rfc6120 (visited on 05/27/2017).

[29] Open Management Group. Data Distribution ServiceTM, V1.4. 2015. URL:http://www.omg.org/spec/DDS/1.4/ (visited on 05/27/2017).

[30] Google. Protocol Buffers. 2017. URL: https://developers.google.com/protocol-buffers/ (visited on 06/20/2017).

[31] IETF. Hypertext Transfer Protocol – HTTP/1.1. 1999. URL: https://www.ietf.org/rfc/rfc2616.txt (visited on 06/01/1999).

[32] OASIS. MQTT Version 3.1.1. 2014. URL: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html (visited on 10/29/2014).

[33] IETF. The Constrained Application Protocol (CoAP). 2014. URL: https://tools.ietf.org/html/rfc7252 (visited on 06/01/2014).

[34] IETF. CoAP (Constrained Application Protocol) over TCP, TLS, and Web-

Sockets draft-ietf-core-coap-tcp-tls-09. 2017. URL: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-09 (visited on 06/01/2017).

[35] IETF. Transport of CoAP over SMS draft-becker-core-coap-sms-gprs-06.2017. URL: https://tools.ietf.org/html/draft- becker- core-coap-sms-gprs-06 (visited on 02/20/2017).

[36] IETF. The Transport Layer Security (TLS) Protocol Version 1.2. 2008. URL:https://tools.ietf.org/html/rfc5246 (visited on 05/27/2017).

http://www.lightreading.com/huawei-mobile-world-congress/year-of-nb-iot-huawei-plans-30-networks-worldwide/d/d-id/730661



https://docs.oracle.com/cd/E19455-01/806-0916/6ja85398m/index.html

https://docs.oracle.com/cd/E19455-01/806-0916/6ja85398m/index.html

https://support.microsoft.com/en-us/help/103884/the-osi-model-s-seven-layers-defined-and-functions-explained



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


https://www.ietf.org/rfc/rfc768.txt



http://www.omg.org/spec/DDS/1.4/

https://developers.google.com/protocol-buffers/

https://developers.google.com/protocol-buffers/



http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html

http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html



https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-09

https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-09

https://tools.ietf.org/html/draft-becker-core-coap-sms-gprs-06

https://tools.ietf.org/html/draft-becker-core-coap-sms-gprs-06


58 BIBLIOGRAPHY

[37] IETF. Datagram Transport Layer Security Version 1.2. 2012. URL: https://tools.ietf.org/html/rfc6347 (visited on 05/27/2017).

[38] J. Mattsson IETF. Overview and Analysis of Overhead Caused by TLS draft-

mattsson-uta-tls-overhead-00. 2014. URL: https : / / tools . ietf . org /html/draft-mattsson-uta-tls-overhead-00 (visited on 07/01/2014).

[39] Olaf Bergmann Klaus Hartke. Datagram Transport Layer Security in Con-

strained Environments. 2017. URL: https://www.ietf.org/proceedings/83/slides/slides-83-lwig-2.pdf (visited on 05/01/2017).

[40] Lammert Bies. Hayes modem AT command set. 2017. URL: https://www.lammertbies.nl/comm/info/hayes- at- commands.html (visited on05/27/2017).

[41] ARM. Cortex-M0 Processor. 2017. URL: https : / / www . arm . com /

products / processors / cortex - m / cortex - m0 . php (visited on05/27/2017).

[42] Atmel. SAM D ARM Cortex-M0+ Microcontrollers. 2017. URL: http://www.atmel.com/products/microcontrollers/arm/sam-d.aspx#samd21

(visited on 05/15/2017).

[43] INA168. 60-V, High-Side, Current Output Current Shunt Monitor. 2001. URL:http://www.ti.com/product/INA168 (visited on 05/15/2017).

[44] EETimes. Embedded Processors by the Numbers. 2017. URL: http://www.eetimes.com/author.asp?doc_id=1287712 (visited on 05/31/2017).

[45] Library of Congress. What is GPS, How does it work. 2017. URL: http :/ / www . loc . gov / rr / scitech / mysteries / global . html (visited on06/04/2017).

[46] Ravi Smith James; Nair. The Architecture of Virtual Machines. 2005. URL:http : / / ieeexplore . ieee . org / document / 1430629/ (visited on06/04/2017).

[47] Erlang. Erlang. 2017. URL: https : / / www . erlang . org/ (visited on06/04/2017).

[48] Plataformatec. Elixir. 2017. URL: https://elixir-lang.org/ (visited on06/04/2017).

[49] Ericsson AB. Erlang/OTP 19.3. 2017. URL: http://erlang.org/doc/(visited on 06/04/2017).

[50] Steve Vinoski Francesco Cesarini. Designing for Scalability with Erlang OTP.USA: OReilly Media, 2016.



https://tools.ietf.org/html/draft-mattsson-uta-tls-overhead-00

https://tools.ietf.org/html/draft-mattsson-uta-tls-overhead-00

https://www.ietf.org/proceedings/83/slides/slides-83-lwig-2.pdf

https://www.ietf.org/proceedings/83/slides/slides-83-lwig-2.pdf

https://www.lammertbies.nl/comm/info/hayes-at-commands.html

https://www.lammertbies.nl/comm/info/hayes-at-commands.html

https://www.arm.com/products/processors/cortex-m/cortex-m0.php

https://www.arm.com/products/processors/cortex-m/cortex-m0.php

http://www.atmel.com/products/microcontrollers/arm/sam-d.aspx#samd21

http://www.atmel.com/products/microcontrollers/arm/sam-d.aspx#samd21

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

http://www.eetimes.com/author.asp?doc_id=1287712

http://www.eetimes.com/author.asp?doc_id=1287712

http://www.loc.gov/rr/scitech/mysteries/global.html

http://www.loc.gov/rr/scitech/mysteries/global.html

http://ieeexplore.ieee.org/document/1430629/

https://www.erlang.org/

https://elixir-lang.org/

http://erlang.org/doc/

BIBLIOGRAPHY 59

[51] Shaling Zhu. Experimental Study on Low Power Wireless Sensor Network Pro-

tocols with Native IP Connectivity for Building Automation. 2017. URL: http://kth.diva-portal.org/smash/get/diva2:862330/FULLTEXT01.pdf

(visited on 07/01/2015).

[52] Péter Szármes Gábor Paller and Gábor Élo. Power Consumption Consid-

erations of GSM sensors in the AgroDat.hu sensor network. 2015. URL:https : / / www . researchgate . net / profile / Gabor _ Paller /

publication/280154945_Power_Consumption_Considerations_of_

GSM-connected_Sensors_in_the_AgroDathu_Sensor_Network/links/

55acfe7108aea3d0868633f9/Power- Consumption- Considerations-

of-GSM-connected-Sensors-in-the-AgroDathu-Sensor-Network.

pdf (visited on 01/01/2015).

[53] EDVARD COLLIN FRIDA LINDBERG. A Study of Technical Solutions for

IoT End Devices and an Evaluation Guide for Their Performance. 2016.URL: http://kth.diva- portal.org/smash/get/diva2:967797/FULLTEXT01.pdf (visited on 05/27/2017).

[54] Péter Szármes Gábor Paller and Gábor Élo. Lightweight Message Authentica-

tion for the Internet of Things. 2014. URL: http://kth.diva-portal.org/smash/get/diva2:765537/FULLTEXT01.pdf (visited on 11/24/2014).

[55] Marco Tiloca. Denial of Service prevention in the IoT. 2015. URL:https : / / www . sics . se / sites / default / files / pub /

marcosecurityseminar2015.pdf (visited on 05/19/2015).

[56] KE’AHI COOPER. Security for the Internet of Things. 2015. URL: http://kth.diva-portal.org/smash/get/diva2:848663/FULLTEXT01.pdf

(visited on 05/27/2017).

[57] angus. Sharing bikes in Shanghai. 2017. URL: https://projectgus.com/2017/04/sharing-bikes-in-shanghai/ (visited on 06/04/2017).

[58] Qian Jiang. The Development of Bike Sharing - a comparison of the Stockholm

and Hangzhoucases. 2011. URL: http://kth.diva-portal.org/smash/get/diva2:403766/FULLTEXT01.pdf (visited on 07/01/2015).

[59] Agile Manifesto. Manifesto for Agile Software Development. 2001. URL:http://agilemanifesto.org/ (visited on 01/01/2001).

[60] Henrik Kniberg. Scrum and XP from the Trenches. USA: C4media, 2007.

[61] Atlassian. The Kanban Methodology. 2017. URL: https://www.atlassian.com/agile/kanban (visited on 05/20/2017).

http://kth.diva-portal.org/smash/get/diva2:862330/FULLTEXT01.pdf


https://www.researchgate.net/profile/Gabor_Paller/publication/280154945_Power_Consumption_Considerations_of_GSM-connected_Sensors_in_the_AgroDathu_Sensor_Network/links/55acfe7108aea3d0868633f9/Power-Consumption-Considerations-of-GSM-connected-Sensors-in-the-AgroDathu-Sensor-Network.pdf










https://www.sics.se/sites/default/files/pub/marcosecurityseminar2015.pdf

https://www.sics.se/sites/default/files/pub/marcosecurityseminar2015.pdf



https://projectgus.com/2017/04/sharing-bikes-in-shanghai/

https://projectgus.com/2017/04/sharing-bikes-in-shanghai/



http://agilemanifesto.org/

https://www.atlassian.com/agile/kanban

https://www.atlassian.com/agile/kanban

60 BIBLIOGRAPHY

[62] Airbrake. Waterfall Model: What Is It and When Should You Use It? 2017.URL: https://airbrake.io/blog/sdlc/waterfall-model (visited on05/12/2017).

[63] RabbitMQ. Rabbit Message Queue. 2017. URL: https://www.rabbitmq.com/ (visited on 06/04/2017).

[64] Microsoft. IoT Hub. 2017. URL: https://cloud.google.com/iot-core/(visited on 06/04/2017).

[65] Google. CLOUD IOT CORE. 2017. URL: https://cloud.google.com/iot-core/ (visited on 06/04/2017).

[66] Amazon. Internet of Things. 2017. URL: https://aws.amazon.com/iot/(visited on 06/04/2017).

[67] Trello. Trello. 2017. URL: https://trello.com/ (visited on 05/27/2017).

[68] Eclipse. Mosquitto, An Open Source MQTT v3.1/v3.1.1 Broker. 2017. URL:https://mosquitto.org/ (visited on 05/27/2017).

[69] Petr Gotthard. Generic Erlang CoAP Client/Server. 2017. URL: https://github.com/gotthardp/gen_coap (visited on 05/27/2017).

[70] Matthias Kovatsch. Copper (Cu) CoAP user-agent for Firefox. 2014. URL:http : / / people . inf . ethz . ch / mkovatsc / copper . php (visited on05/27/2017).

[71] Chris Mccord. Phoenix Framwork. 2017. URL: http : / / www .

phoenixframework.org/ (visited on 05/27/2017).

[72] Simcomm2m. SIM800. 2017. URL: http://simcomm2m.com/En/module/detail.aspx?id=138.

[73] Electrodragon. GSM GPRS A6 Module. 2017. URL: http : / / www .

electrodragon.com/product/gsm-grmgprs-a6-module.

[74] IETF. Observing Resources in the Constrained Application Protocol (CoAP).2015. URL: https : / / tools . ietf . org / html / rfc7641 (visited on05/27/2017).

[75] FreeSoft. Robustness Principle. 2017. URL: http://www.freesoft.org/CIE/RFC/1812/9.htm (visited on 06/04/2017).

[76] IETF. Cross-Protocol Proxying between CoAP and HTTP. 2017. URL: https://tools.ietf.org/html/rfc7252#section-10 (visited on 06/05/2017).

[77] IETF. Hypertext Transfer Protocol Version 2 (HTTP/2). 2015. URL: https://tools.ietf.org/html/rfc7540 (visited on 05/01/2015).

https://airbrake.io/blog/sdlc/waterfall-model

https://www.rabbitmq.com/

https://www.rabbitmq.com/

https://cloud.google.com/iot-core/



https://aws.amazon.com/iot/

https://trello.com/

https://mosquitto.org/

https://github.com/gotthardp/gen_coap

https://github.com/gotthardp/gen_coap

http://people.inf.ethz.ch/mkovatsc/copper.php

http://www.phoenixframework.org/

http://www.phoenixframework.org/

http://simcomm2m.com/En/module/detail.aspx?id=138

http://simcomm2m.com/En/module/detail.aspx?id=138

http://www.electrodragon.com/product/gsm-grmgprs-a6-module

http://www.electrodragon.com/product/gsm-grmgprs-a6-module


http://www.freesoft.org/CIE/RFC/1812/9.htm

http://www.freesoft.org/CIE/RFC/1812/9.htm

https://tools.ietf.org/html/rfc7252#section-10

https://tools.ietf.org/html/rfc7252#section-10



61

Appendix A

Appendix A

A.1 Communication Protocols Binary Sequences

A.1.1 Small Packet Test Binary Sequences

MQTT

connect b’\x10\x14\x00\x04MQTT\x04\x02\x00\x00\x00\x08LFzaqcUw’ 22

publish b’0\x1d\x00\x0c/temperature\x8fw"value": 24’ 31

disconnect b’\xe0\x00’ 2

CoAP

post b’P\x02\x00\x00\xbc/temperature\xff"value": 24’ 31’

HTTP

post b’POST /temperature HTTP/1.1\r\ncontent-type: application/json\r\nhost: 20

7.154.232.100\r\nconnection: close\r\ncontent-length: 13\r\n\r\n"value": 24’ 1

37

A.1.2 Large Packet Test Binary Sequences

MQTT

connect b’\x10\x14\x00\x04MQTT\x04\x02\x00\x00\x00\x08VPdXiNMv’ 22

publish b’0m\x00\x05/data\x98\xa2AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA’ 111


CoAP

post b’P\x02\x00\x00\xb5/data\xffAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

62 Appendix A. Appendix A

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA’ 111

HTTP

post b’POST /data HTTP/1.1\r\nhost: 207.154.232.100\r\ncontent-length: 100\r\n

connection: close\r\ncontent-type: application/json\r\n\r\nAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAA’ 218

A.1.3 Multiple Small Packets Binary Sequences

MQTT

connect b’\x10\x14\x00\x04MQTT\x04\x02\x00\x00\x00\x08PLD02wby’ 22

publish b’0\n\x00\x05/data\xcc\x86A’ 12 x10


CoAP

post b’P\x02\x00\x00\xb5/data\xffA’ 12 x10

HTTP

post b’POST /data HTTP/1.1\r\ncontent-type: application/json\r\ncontent-length

: 1\r\nconnection: close\r\nhost: 207.154.232.100\r\n\r\nA’ 117 x10

TRITA TRITA-ICT-EX-2017:108

www.kth.se

Communication protocols for mid-range mobile IoT devices1181232/FULLTEXT01.pdf · Transport(MQTT)...

Documents

Transcript of Communication protocols for mid-range mobile IoT devices1181232/FULLTEXT01.pdf · Transport(MQTT)...