Embed Size (px)
Citation preview
Internet of Things for the Smart Home
António Gonçalves Vian Costa
Thesis to obtain the Master of Science Degree in
Electrical and Computer Engineering
Supervisor: Prof. Maria Helena da Costa Matos Sarmento
Examination Committee
Chairperson: Prof. Gonçalo Nuno Gomes Tavares
Supervisor: Prof. Maria Helena da Costa Matos Sarmento
Member of the Committee: Prof. Rui António Policarpo Duarte
June 2018
ii
Declaration
I declare that this document is an original work of my own authorship and that it fulfills all the requirements
of the Code of Conduct and Good Practices of the Universidade de Lisboa.
iii
iv
Acknowledgements
This dissertation marks the end of a long journey. One that proved itself challenging but worth it and
now very welcomed. The Internet of Things was a topic that I wanted to explore even before I took on
this thesis, and is one that kept me interested and engaged since the beginning. Through it, I learned a
lot, and my interest in it only grew. For this final work, I would like to thank the people who helped
bring this project to fruition during the time I worked on it and throughout my university years.
To Professor Maria Helena da Costa Matos Sarmento for the guidance in this work and the interest shown
in the topic. The availability to help, not only through meetings, but also for the support, understanding
and the patience shown at every step of the way.
To Narrownet, for the availability to help and the support shown.
To my parents for all the support provided even at the worst times. Not only for this thesis but throughout
all of my education. A special thank you to my Mother, for whom I have the deepest admiration, for the
emotional support and never wavering in the belief that I could do it.
A special thanks to my godparents for the support and peace of mind that they provided, for without
their help these final steps on my education would not have been possible. To the rest of my family, too
many to thank by name, for all their support, understanding, laughter and jokes.
Lastly and not least important to all my friends. In particular to Rui, Zé Pedro, João, Manuel, Zé Miguel,
Margarida and Marta for their continued friendship and support.
To all of them and more, I dedicate this work.
v
vi
Abstract
As increasingly more things become connected to the internet, the Internet of Things is becoming a reality
faster than expected. Smart homes, a setting in which the Internet of Things is predicted to have a
high impact on the betterment of everyday lives, is a topic of high interest. Allied to other technological
advances like cloud computing, machine learning, and miniaturization, the Internet of Things is turning
devices away from performing taxing computing skills. Here, low power wide area networks are vital,
providing energy efficient devices at low costs. Sigfox and LoRa are two significant players in this field.
In this work a prototype using Sigfox technology was developed for the smart home and a study was
made on possible consumer interaction solutions, using various Internet of Things web platforms. Another
objective, to compare the Sigfox prototype with LoRa technology, is also achieved. It is concluded that
Sigfox, because of its limitations, cannot be the only technology used in a smart home. LoRa technology,
while offering more freedom of use, has a more difficult and complex implementation and is still behind on
the simplicity offered by the Sigfox infrastructure.
Keywords: Internet of Things, Smart Home, Low Power Wide Area Network, Sigfox, LoRa, IoT Platforms
vii
viii
Resumo
Com o aumento de coisas ligadas à Internet, a Internet das Coisas está a tornar-se realidade mais
rapidamente do que o esperado. As casas inteligentes, um ramo onde se espera que a Internet das Coisas
tenha grande impacto para o melhoramento da vida das pessoas, é um dos tópicos de mais interesse. Aliada
à evolução de outras tecnologias como cloud computing, machine learning e miniaturização, a Internet das
Coisas está a permitir que as tarefas mais exigentes de processamento não sejam feitas nos dispositivos.
Aqui, entram as redes de baixa potência e longo alcance (Low Power Wide Area Network), onde dispositivos
de baixo consumo de energia são comercializados a baixos custos. Sigfox e LoRa encontram-se, neste
espaço, como duas das maiores tecnologias em expansão. Neste trabalho foi realizado um protótipo de
um sistema para uma casa inteligente com tecnologia Sigfox. Foram também analisadas plataformas
de Internet das Coisas que permitem ao consumidor gerir a informação obtida. Outro objectivo, o de
comparar o protótipo Sigfox com a tecnologia LoRa, é também alcançado. Conclui-se que, pelas limitações
tecnológicas da Sigfox, esta tecnologia nunca poderá ser a única utilizada numa casa inteligente. A
tecnologia LoRa, embora oferecendo mais liberdade na sua utilização, tem uma implementação mais difícil
e complexa e ainda está atrás da simplicidade oferecida pela infraestrutura Sigfox.
Palavras-chave: Internet das Coisas, Casa Inteligente, Low Power Wide Area Network, Sigfox, LoRa,
Plataformas IoT
ix
x
Table of Contents
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
List of Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Structure of the Dissertation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 The Internet of Things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 Defining IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 The IoT Reference Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5 Privacy and Legal Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.6 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 Communication Technologies for the IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1 Wireless Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Low Power Wide Area Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.1 Sigfox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.2 LoRa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.3 Differences between Sigfox and LoRa . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3 State of the Art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
xi
4 Smart Home Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1 Smart Home Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 Sigfox Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.1 TD1208 Evaluation Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.2 SmartEverything Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.3 Sigfox Radio Shield for Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.4 Sigfox IoT Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3 LoRa Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3.1 RadioHead Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3.2 LoRaWAN Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5 Results and Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1 Sigfox Boards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2 LoRa Dragino Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.1 Developed Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Annex A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
xii
List of Figures
Figure 1.1: New dimension in the ICT paradigm adapted from [1]. . . . . . . . . . . . . . . . . . 3
Figure 2.1: Technical overview of the IoT [5]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Figure 2.2: IoT reference model [28]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Figure 3.1: Range versus bandwidth [58]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Figure 3.2: The Sigfox architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figure 3.3: A detailed view of the Sigfox cloud [72]. . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 3.4: LoRaWAN device classes [79]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figure 3.5: The LoRa architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figure 4.1: Smart home architecture solution using only cloud services. . . . . . . . . . . . . . . 36
Figure 4.2: Smart home architecture solution using IoT platforms. . . . . . . . . . . . . . . . . . 36
Figure 4.3: Proposed smart home architecture using Sigfox technology. . . . . . . . . . . . . . . . 37
Figure 4.4: View of a Sigfox email callback. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Figure 4.5: Experiments conducted on the moisture and temperature sensors. . . . . . . . . . . . 41
Figure 4.6: Example of a Sigfox message at the back-end. . . . . . . . . . . . . . . . . . . . . . . 41
Figure 4.7: Battery tests conducted on the prototype. . . . . . . . . . . . . . . . . . . . . . . . . 41
Figure 4.8: Callback configuration for the Thinger Platform. . . . . . . . . . . . . . . . . . . . . 43
Figure 4.9: Proposed smart home architecture using LoRa technology. . . . . . . . . . . . . . . . 44
Figure 4.10: Dragino devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figure 4.11: A compressed view of the LG01 gateway interface. . . . . . . . . . . . . . . . . . . . 46
Figure 4.12: The ThingSpeak Platform experiment. . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Figure 4.13: LoRa/GPS shield experiment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Figure 5.1: Example of a Sigfox message received at the Carriots IoT platform. . . . . . . . . . . 50
Figure 5.2: The SmartEverything board [138]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Figure 5.3: Cooking hacks Sigfox radio shield and module [114]. . . . . . . . . . . . . . . . . . . . 52
Figure 5.4: Custom payload configuration at the Sigfox back-end. . . . . . . . . . . . . . . . . . . 52
Figure 5.5: Custom payload display attempt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Figure 5.6: Sigfox module fails to switch on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Figure 5.7: A Sigfox warning event for a break in message sequence. . . . . . . . . . . . . . . . . 53
Figure 5.8: Example of an email received using a Sigfox data callback. . . . . . . . . . . . . . . . 54
xiii
Figure 5.9: Callback error to Cloudthing platform. . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figure 5.10: Data received at the Wia platform. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figure 5.11: Tago dashboard view of the data widget. . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figure 5.12: Amazon AWS DynamoDB table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figure 5.13: Results obtained with Amazon AWS platform . . . . . . . . . . . . . . . . . . . . . . 57
Figure 5.14: Custom signals received at the Databoom platform. . . . . . . . . . . . . . . . . . . . 58
Figure 5.15: Custom IoT dashboard built at the Databoom Platform. . . . . . . . . . . . . . . . . 58
Figure 5.16: Thinger platform custom dashboard. . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Figure 5.17: LoRa device and gateway tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Figure 5.18: Temperature and humidity values in ThingSpeak platform. . . . . . . . . . . . . . . . 61
Figure 5.19: The successful reception of the payload at the TTN platform. . . . . . . . . . . . . . 62
Figure 5.20: The unsuccessful reception of the GPS signal at TTN. . . . . . . . . . . . . . . . . . 62
xiv
List of Tables
Table 2.1: The Internet of Things three main segments. . . . . . . . . . . . . . . . . . . . . . . . 10
Table 2.2: Nine settings where IoT creates value (adapted from [22]). . . . . . . . . . . . . . . . . 10
Table 2.3: Complementary aspects of cloud computing and the IoT [30]. . . . . . . . . . . . . . . 14
Table 2.4: Possible layers of a fog computing architecture (adapted from [38]). . . . . . . . . . . 15
Table 2.5: IoT attacks characterized by type [15]. . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Table 3.1: Short and long range IoT Technologies [59]. . . . . . . . . . . . . . . . . . . . . . . . . 20
Table 3.2: Differences between Sigfox and LoRa/LoRaWAN. . . . . . . . . . . . . . . . . . . . . 30
Table 5.1: Shield solutions for the Sigfox module. . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Table 5.2: Shield solutions for the LoRa module. . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
xv
xvi
List of Acronyms
3GPP 3rd Generation Partnership Project
ABP Activation By Personalization
BPSK Binary Phase Shift Keying
BSS Business Support System
CSS Chirp Spread Spectrum
DDoS Distributed Denial-of-Service
DSL Digital Subscriber Lines
ETSI European Telecommunications Standards Institute
FSK Frequency Shift Keying
FTC Federal Trade Commission
IEEE Institute of Electrical and Electronics Engineers
IoE Internet of Everything
IoT Internet of Things
IoTSF Internet of Things Security Foundation
IP Internet Protocol
ISM Industrial, Scientific and Medical
ISO International Organization for Standardization
ITU International Telecommunication Union
LPWAN Low Power Wide Area Network
LTE Long-term Evolution
M2M Machine-to-Machine
MTC Machine Type Communications
xvii
OSS Operations Support System
OTAA Over The Air Activation
QoS Quality of Service
RFID Radio-frequency Identification
SoC System on a Chip
UNB Ultra-narrow Band
xviii
xix
xx
Chapter 1
Introduction
This chapter presents a brief overview of the scope and history of the Internet of Things as well as the
motivations that led to choose this project. The objectives established for the thesis and the work structure
are presented.
1
1.1 Motivation
The introduction of the personal computer into society changed the way people live their lives, from how
they interact with each other to how they conduct business. Today, computers can be found everywhere
and with them came a series of new technologies that helped shape the world. One of these technologies
was the Internet. Mark Weiser, a computer scientist who coined the term of ubiquitous computing [1],
meaning devices which can be used anytime, anyplace and in any format, said in 1991 that "The most
profound technologies are those that disappear. They weave themselves into the fabric of everyday life
until they are indistinguishable from it" [2].
Now the next revolution is coming in the form of the Internet of Things (IoT). Although the concept is said
to have originated in 1991, as ubiquitous computing, the term was first coined in 1999 by Kevin Ashton
during a presentation on the use of Radio-frequency Identification (RFID) [3]. Still, it was only in the past
years that the IoT has begun gaining momentum, not only in the technology side, due to the appearance
of new technologies, but also on the marketing side. Today, it can be found on the industrial, commercial
and consumer markets. However, its meaning and definition are still in a fog. It comes attached with
many names and related to a series of technologies, such as Internet of Everything (IoE), the industrial
Internet, industry 4.0. [4], cloud computing, Machine-to-Machine (M2M) communications, and big data,
to name a few. All these concepts and technologies are, in a way, a part of IoT and a part of a world
connected to the internet. In the Information and Communications Technology (ICT) paradigm, which is
focused on representing all things relating to communications in computer and digital technologies, the
IoT adds a new dimension, the "Any Thing Connection", shown in figure 1.1. This new dimension joins
the already existing "Any Time" and "Any Place" connections [5] which refer to communications that can
be made independently of the time or place, whether outdoors, indoors, at night or during the day. The
new "Any Thing" connection enables communications between: personal computers; humans, without the
use of PCs; humans and IoT devices; and between IoT devices.
With this new dimension a series of new business opportunities arise. With predictions in the range of 20
to 30 billion connected devices by 2020 [6], global spending of 1.4 trillion dollars by 2021 [7] and the fact
that today billions of devices generate more than two Exabyte’s of data each day [8] confirm that IoT is
quickly rising to a definite stay in our everyday lives. According to a Verizon report [9], 2016 was the year
that the IoT gained the most momentum and 2017 gave definite proof that IoT solutions are the next big
step. In the same report, 73% of executives were either researching or deploying IoT related solutions in
their companies.
Smart home, e-Home, automated or connected home is a living environment filled with advanced automatic
computer systems [10], with its primary function to improve and simplify the quality of life of its inhabitants.
In a Gartner [11] report it was estimated that by 2022 a typical family home will contain 500 smart
devices and today the smart home represents one of the fastest growing settings of IoT. This growing
interest in smart homes can be seen in another study, made in the UK by Deloitte [12], where 66% of
2
Figure 1.1: New dimension in the ICT paradigm adapted from [1].
consumers agreed that connected devices had the potential to make their lives more comfortable. Advances
in the smart home setting can already be seen today, as smart assistants coupled with advancements in
AI, pushed by big technology companies, enable things like smart lighting and smart appliances. Other
devices, such as thermostats, smart locks, health monitoring and pet tracking systems are also entering
the home of consumers. One market which has seen tremendous growth due to smart home technology
development is the IoT platform services, as seen in a 2017 report which states that IoT platforms, in the
IoT consumer segment, have a 21% focus on the smart home [13]. Smart homes have very high market
potential, but there are also many issues to overcome from the user point of view, such as [11]:
• Security: one of the most critical aspects for customers. It represents the steps taken to protect the
home, either through hardware or software security, from such threats as Internet attacks, robberies
or IoT device tampering.
• Ease of Use: the system must be easy to understand and work with, offering a comfortable experience.
• Cost: price stands as one of the most delicate aspects in all business areas and can hinder smart
home device adoption.
• Convenience: problems must be easy to solve; if possible, without user intervention. This makes
monitoring, control and intelligence vital functions of the smart home.
• Energy Efficiency: electricity represents significant costs in most countries and it is where Low Power
Wide Area Network (LPWAN) technologies are starting to take center stage as leading devices in
energy consumption and battery life.
• Privacy: the costumer expects that his personal and home information remain guarded. For example,
in cases where the devices have a direct internet connection, it is imperative to guarantee that they
have the necessary protection against possible security attacks.
3
In the years to come, the Internet of Things is sure to become a large part of society and will be
incorporated in every setting possible, blending its way into cities, homes, hospitals and more, until it
merges into the fabric of everyday lives just as Mark Weiser predicted. The most important feature of
IoT is the impact it will have on several aspects of the daily lives of its users, in both the working and
domestic fields [14].
1.2 Objectives
The main objective of this work is to develop a smart home system using LPWAN IoT technologies. To
achieve this, specific objectives were defined:
• To study IoT, its challenges and technologies with a focus on LPWAN.
• To analyze the two most significant LPWAN technologies in the market, Sigfox and LoRa, while
also studying their differences in the smart home context.
• To study the various IoT platforms that have a focus on the smart home setting.
• To create a prototype using Sigfox technology and to synchronize it with IoT platforms chosen, to
obtain a user friendly smart home system.
• To create a prototype using LoRa technology and, like Sigfox, to synchronize it with the IoT
platforms chosen.
• And finally, to compare the technologies and analyze the results from both experiences.
For each topic discussed in the following chapters there are several papers addressing each subject at
length, whether it be IoT [5], security [15], rights [16], LPWANs [17], Sigfox and LoRa [18] technologies.
In fact, for each of the latter, a different thesis could be written, covering the subject with a more in-depth
focus. This work provides an overview on several of these topics and a basic understanding regarding an
IoT project, and brings innovation by building a IoT smart home project from its most basic stage, the
devices from which information is captured, to the very last, where through the use of IoT platforms a
customer may use the information for their gain.
4
1.3 Structure of the Dissertation
The present document is divided into six chapters and one annex.
In Chapter 2, the definition, the architectural reference model and other fundamental concepts of IoT are
addressed. An overview of technologies related to IoT, like cloud computing and M2M communications,
as well as the challenges that IoT faces and their impact on its adoption are also discussed.
In Chapter 3, some of the communication technologies behind IoT are reviewed, with a focus on LPWAN.
A more in-depth study on Sigfox and LoRa technologies is presented as well as a discussion on their
differences. An analysis of the state of the art is conducted.
In Chapter 4, the prototype developed with Sigfox is presented along with an explanation of the architecture
used and the steps taken to synchronize the service with the IoT platforms tested. The testing and
implementation of LoRa technology as well as the steps taken for the synchronization of the devices with
their respective IoT platforms are detailed.
In Chapter 5, the results and the analysis of the work are presented and the problems faced during the
project are addressed.
In Chapter 6, an overview of the work is presented with its main objectives revisited and discussed. The
chapter ends with some ideas regarding the possible continuation of this work.
All work presented in this thesis was made using a Macintosh MacBook Pro. Icons used in several figures
were made by Freepik and Kiranshastry and can be found in [19]. The annex contains code created for
the prototype used in the work.
5
6
Chapter 2
The Internet of Things
In this chapter, the basic concepts and other fundamental aspects of IoT are addressed. Challenges faced
by IoT, such as security, privacy, standards, rights and legal issues are also reviewed.
7
2.1 Defining IoT
In recent years the IoT has become a favorite topic of discussion, an industry buzzword but also a clouded
term. There are several advances in technology fields which prompted the appearance of IoT. These
technologies continue to evolve alongside it, providing it with new ways for implementation. Among them
are [20]:
• Ubiquitous Connectivity: more devices at lower costs coupled with new technologies and faster
connection speeds, are slowly connecting the world to the internet.
• Widespread adoption of IP-based networking: more devices connected to the internet and better
software programs enable an IoT connected world.
• Miniaturization: computers with better performance while, at the same time, diminishing in size,
price and power consumption, speed the advance of computer technologies.
• Advances in Data Analytics: new algorithms capable of solving more complex tasks, better and
bigger data storage and higher computing power enable new ways for data analysis that can generate
added value, information and knowledge.
• Cloud Computing: allows for small and distributed devices to use more powerful servers capable of
advanced analytic and control capabilities for the processing, management and storing of information.
There is not a clear consensus on what IoT is. Different organizations have put forward slightly different
definitions. According to the International Telecommunication Union (ITU) it is “a global infrastructure
for the information society, enabling advanced services by interconnecting (physical and virtual) things
based on existing and evolving interoperable information and communication technologies (ICT)” [5].
Figure 2.1 shows a technical overview of the IoT.
As the figure shows, in IoT there are physical and virtual things. The physical things are objects which
can be sensed, actuated and connected. Examples include machines, goods, appliances, buildings, vehicles,
animals, plants, soil and even people. The virtual things are movies, music, books, tickets and application
software, among others, which can be stored, processed and accessed.
Physical things are connected to devices which in turn can be represented in the information world by one
or more virtual things, with the latter being able to exist without being associated with a physical thing.
The devices are hardware equipment capable of communication and, if necessary, with sensing, actuation,
data capture, data storage and data processing capabilities. They collect information from the physical
world and send it to the information world. They can communicate between themselves in three ways:
through communication networks, shown in the figure by the "b" connection; without communication
networks, shown by the "c" connection; or with gateways, which can be compared to bridges responsible
for ensuring that the information arrives at its proper destination, shown by the "a" connection. Virtual
8
Figure 2.1: Technical overview of the IoT [5].
things can also exchange information without the need of the physical things they are connected to. The
devices in figure 2.1 can be categorized into four different types [5]:
• Data-carrying devices: they connect to physical things in order to bridge the gap between the latter
and communication networks, for example RFID tags.
• Data-capturing devices: they have the capability to interact with physical things, for example devices
capable of reading QR codes, bar codes and RFID tags.
• Sensing and actuating devices: they interact with physical things in the environment. They detect
and measure information or convert signals into operations, respectively.
• General devices: with processing and communication capabilities such as smart phones, home
appliances and industrial machines.
The devices, described previously, are used in many different applications. These applications can be
grouped into several categories. However there is not a consensus on these classifications. In [21] the IoT
segmentation is presented in table 2.1 and in [22] in table 2.2.
In table 2.1 the consumer segment is directly related to an individual or family. Normally devices in this
segment have shelf lives between months and years with limited maintenance, with an individual capable
of having numerous of these devices. The commercial segment shares characteristics of both the consumer
and industrial IoT. It deals with inventory, tracking, management and data analysis. In some cases this
segment is grouped with the industrial segment. Lastly, the industrial IoT, is the area where solutions are
custom tailored for each application [23].
9
Table 2.1: The Internet of Things three main segments.
Consumer IoT Commercial IoT Industrial IoT
Smart Appliances Retail Heavy Machinery
Wearables Asset Tracking Transportation
Auto-Industry Medical Equipment Power Plants
Smart Homes Smart Cities
The segmentation in table 2.2 presents the nine settings in which IoT is expected to create value for
industry and users alike. It was made by reviewing three hundred IoT applications. The categorization
by settings was proposed as a better alternative to the more conventional approach of categorizing
vertical industry markets. For example, in a city setting sensors in cars can be used by an automaker to
determine when a vehicle needs maintenance, but they can also be used to help manage traffic congestions,
maximizing the use of smart devices.
Table 2.2: Nine settings where IoT creates value (adapted from [22]).
Setting Description Examples
HumanDevices attached to or
inside the human body
Devices to monitor and maintain human health;
disease management, increased fitness, higher productivity
Home Residential buildings Home controllers and security systems
RetailWhere commercial
exchange takes place
Stores, banks, restaurants, arenas, self-checkouts,
in-store offers, inventory optimization
Offices WorkspacesEnergy management and security in office buildings;
improved productivity, including for mobile employees
FactoriesStandardized production
environments
Hospitals and farms; operating efficiencies,
optimizing equipment use and inventory
WorksitesCustom production
environments
Mining, oil and gas, construction; operating efficiencies,
predictive maintenance, health and safety
VehiclesSystems inside
vehicles
Cars, trucks, ships, aircraft and trains;
condition-based maintenance, usage-based design, pre-sales analytics
Cities Urban environments
Public spaces and infrastructure in urban settings;
adaptive traffic control, smart meters, environmental
monitoring, resource management
OutsideBetween urban environments
(and outside other settings)
Railroad tracks, autonomous vehicles and flight navigation;
real-time routing, connected navigation, shipment tracking
10
2.2 The IoT Reference Model
There is no standard architecture for IoT. Depending on the communication technology used, or re-
quirements for the project, the architectures may use a different number of layers [24]. Some differ
in their abstraction levels, going into considerable detail on the layers used. Other go beyond IoT to
include business layers [25], manufacturing and logistic details, while others focus on the industry aspects.
Reference models proposed for the IoT, with the status on their development can be found in [26]. One
of the most critical technologies for IoT architecture [27], that finds itself under the IoT umbrella, its
Machine-to-Machine (M2M) communications, sometimes referred as Machine Type Communications
(MTC). Considered a key enabler for IoT, M2M communications is how mechanical or electronic devices
communicate and share information with each other and with other applications, most of the time without
the intervention of a human counterpart.
The International Telecommunication Union (ITU) proposed reference model for IoT is the one that
better applies to a higher number of solutions, because of its level of abstraction. Figure 2.2 presents this
architecture consisting of four layers: the device, the network, the service and application support and the
applications layer. Present in all these layers are management and security capabilities.
Figure 2.2: IoT reference model [28].
The device layer, sometimes referred to as the perception or sensing layer, is composed by devices and
gateways. The device capabilities are responsible for tasks such as identification, gathering and uploading
11
information from the environment or from the thing they are connected to. Devices may also support
"sleeping" and "waking-up" features to save power and can build networks in an ad-hoc manner in
scenarios where increased scalability and quick deployment may be needed [5]. Gateways are protocol
converters and their capabilities are needed when communications at the device layer differ from the ones
used at the network layer, for example, when a Sigfox communication is used at the device layer and
a 3G communication is used at the network layer. For this reason gateway capabilities need multiple
interfaces support. At the device layer wired or wireless technologies such as ZigBee, Bluetooth, Wi-Fi,
Sigfox, LoRa, 2G, 3G, Long-term Evolution (LTE) and Ethernet can be used. Gateways are not always
necessary, for example when the protocol used in the device is the same as the network layer and, in that
case, the exchange of information is done directly between the device and the communication network.
The network layer is responsible for the transport and networking capabilities. The networking capabilities
connect things to networks and maintain the connectivity. They include functions for access control,
mobility management, routing and resource allocation. The transport capabilities are in charge of assuring
the transport of the IoT application data, from the device layer to the service layer, and IoT-related
control and management information. The network layer is capable of supporting network layer protocols
such as IPv4 and IPv6, cellular networks (2G, 3G and LTE) and various technologies, such as Ethernet,
Wi-Fi and Digital Subscriber Lines (DSL) among others [28]. One important aspect regarding this layer is
the increasing number of IoT devices connected to the internet, which the current IPv4 network protocol
cannot support, due to address limitations. As such IPv6 will prove critical in the advancement and
adoption of IoT, playing a major role in handling the network layer scalability.
The service and application support layer, also called the middleware layer, creates and manages services
required by users or applications. It is a software layer responsible for generic support capabilities that can
be used for different IoT applications like data processing or data storage as well as specific capabilities
that are catered to specific applications. It is on this layer that the management of data, search engines,
communication and information exchange and storage occurs [29]. In [27] an architectural framework for
the M2M service layer was proposed, positioned between the application layer and network layer of the
IoT reference model. In it M2M is be responsible for capabilities such as device discovery and registration,
identification, naming and addressing, group management, location provisioning, accounting, and charging,
among others.
The application layer, is responsible for the interaction methods with users or applications. This layer
contains the IoT applications, corresponding to the settings described in table 2.2, such as smart home,
e-health, smart-grids, etc. It is at this layer that the user gets important real-time information [24].
The security and management capabilities are transversal to all layers of IoT architecture. Both are
divided into general and specific capabilities. In security, the generic capabilities include authorization,
authentication, privacy protection and data confidentiality. The specific capabilities depend on the IoT
application in use and can be, for example, tighter security requirements or better mobile payment security.
In management, the generic capabilities include functions such as device management, for example,
12
remote device activation and deactivation, local network topology management, traffic and congestion
management and status monitoring and control. Specific capabilities are normally application specific.
2.3 Cloud Computing
Cloud computing is way to store, manage and process data in a network server, which is hosted on the
Internet, instead of using a local server or personal computer. It eases the process of collecting and
processing the information from the IoT devices, and also enables the rapid setup of new ones, lowering
the costs for the deployment of IoT solutions and complex data processing [30]. The cloud handles the
data flow to and from the client, data synchronization between devices and data processing [8]. It is in
the cloud that all the information from the billions of IoT devices is stored, processed and analyzed.
The advantages offered by the cloud to IoT are better seen when one considers the complementary aspects
of both technologies as shown in table 2.3. The cloud acts as a centralized manager that can see all the
applications requiring computational effort, and therefore reallocate its resources to better manage its
demands. There are three main drivers for cloud usage in IoT [30]:
• Communication: the cloud offers low cost solutions to connect, track, and manage any thing from
anywhere at any time by using web portals and specific applications. Coupled with high speed
networks, monitoring and control of remote things, their coordination, communication and real-time
access to the produced data, becomes possible.
• Storage: cloud offers the most convenient and cost effective solution to deal with the data produced
by IoT. It enables new opportunities for data aggregation, integration, and sharing with third
parties.
• Computation: with virtually unlimited processing capabilities, performing real-time data analysis
to implement scalable, real-time sensor-centric applications, for managing complex events and for
supporting task offloading for energy saving, becomes possible for IoT solutions.
For LPWAN technologies, cloud computing takes an even bigger role as report [31] shows. In it, IoT
devices are separated by their computational abilities where LPWAN solutions were found to rely heavily
on the cloud, due to their low computational abilities, for data storage and management, focusing only on
data acquisition.
The cloud can also offer opportunities to implement applications and services that exploit the things and
the data they produce, for example, IoT platforms. These platforms aim to reduce development risk and
cost so that companies can bring products to the market faster and more easily. They are capable of
displaying the information sent from the devices in a easy to use and appealing way, giving users a new
way to interact with their devices and companies a way to manage their fleet. In [32] a list of 450 IoT
13
Table 2.3: Complementary aspects of cloud computing and the IoT [30].
IoT Cloud
Displacement Pervasive Centralized
Reachability Limited Ubiquitous
Components Real world things Virtual resources
Computational capabilities Limited Virtually unlimited
Storage Limited or none Virtually unlimited
Role of the Internet Point of convergence Means for delivering services
Big data Source Means to manage
Platform companies is presented, where big technology companies, like Microsoft [33], Amazon [34] and
Google [35] already offer IoT platform solutions.
Big Data is another new term born from the continued expansion of cloud computing and IoT. It represents
not only the large amounts of data that the cloud stores, but also what can be gained by managing that
data, labeling, processing and analyzing it. IoT is expected to generate most of the information for big
data, which coupled with the benefits of the cloud will enable the possibility to perform extremely complex
analysis, data driven decision making and develop better prediction algorithms at low costs [30].
IoT cloud computing solutions bring some challenges as well [36], such as: the cost of the transfer may
be high, depending on the amount of information; storing large amounts of data on the cloud may be
expensive; Internet access may be unavailable, unreliable and slow, or congested by big data transmissions;
Internet transmissions may increase the probability of information leakage; the devices that do not have
the necessary security measures may be targeted for Distributed Denial-of-Service (DDoS) attacks; and
others. Fog computing, sometimes referred as edge computing, solves most of aforementioned problems.
Fog computing acts as a middle cloud between the devices and the cloud, moving closer to the things
that produce and act on IoT data. Any device with computing and storage capabilities that has network
connectivity may act as a fog node. Some of the most important characteristics of fog computing solutions
are [37]: fast transmission speeds; wide-spread geographical distribution; mobility; and a very large number
of nodes.
Table 2.4 shows the differences between the layers of fog nodes and the cloud. After receiving information
from the things it is then up to the fog IoT applications to decide where the data should be sent for analysis.
The most time-sensitive information is acted upon by the fog nodes closest to the things generating the
data, as shown in the table. Data that can wait seconds or even minutes for action can be passed along to
an aggregation node for further analysis and action. Finally, the data which is less time sensitive can be
sent to the cloud for storage, historical analysis and big data analytics. Examples of devices which may
take advantage of fog computing are generally time sensitive, such as opening doors, zooming on security
cameras, opening pressure reading valves, switches and routers.
14
Table 2.4: Possible layers of a fog computing architecture (adapted from [38]).
Fog Nodes Close to IoT Devices Fog Aggregation Nodes Cloud Services
Response time Milliseconds to subsecond Seconds to minutes Minutes, days, weeks
Application examplesTouch communications,
telemedicine and training
Visualization,
Simple analytics
Big data analytics,
Graphical dashboards
Data storage duration TransientShort duration: hours,
days, or weeksMonths or years
Geographic coverage Local: one city block Wider: entire cities Global
2.4 Standards
Standardization brings a lot of benefits to technology areas but it can also be a very slow process, hindering
rapid success or adhesion. According to [22] 40% of the IoT total value that can be unlocked requires
different IoT systems to work together.
There are several organizations currently working on IoT standards, such as: the European Telecommuni-
cations Standards Institute (ETSI) [39], the Institute of Electrical and Electronics Engineers (IEEE) [40],
the International Organization for Standardization (ISO) [41], and the International Telecommunication
Union (ITU) [42]. The European Commission is also working in IoT standardization, launching a paper
[43] on the standardization requirements for IoT technologies where the current standards are reviewed,
the gaps are discussed and recommendations for the future are presented. A table with all organizations
working on IoT standards and their standardization activities can be found in [44].
There were not found any standards from ETSI specifically relating to IoT. However the organization has
various standards under development which relate to technologies associated with it. Most of these are
about M2M communications and, for example, the impact that smart city activity could have on IoT
environments.
IEEE was the organization found with most standards associated to IoT, but like with ETSI, specific
ones for IoT, were not found. It has eighty IoT related standards, such has wireless access in vehicular
environments, health informatics and others like Ethernet standards which, although under the IoT
umbrella standard division, are not about IoT.
ISO has a technical committee, the ISO/IEC JTC 1/SC 41, with a scope on the IoT and related technologies.
These include sensor networks and wearable technologies. It has fifteen published standards focusing
on sensor networks, underwater acoustic sensor networks and IoT use cases. Nine others are currently
under development, for example on IoT definition and vocabulary, the interoperability in IoT systems,
underwater acoustic sensor networks and the IoT reference architecture.
15
ITU was found to have only e-health IoT related standards, and a recommendation specific to IoT
technology. The recommendation gives an overview on the technology, its scope and reference model [5].
Other recommendations, such as how M2M can be incorporated in IoT architecture were also found.
When it comes to cellular technologies used in IoT, the organization responsible for developing standards is
the 3rd Generation Partnership Project (3GPP), which is composed of seven telecommunications standard
development organizations. The 3GPP has continued to move forward in the standardization of IoT
related technologies. NB-IoT, a promising low power technology has seen, in 2016, its standardization
complete, with the Release 13 specification [45]. The organization now turns to the introduction of 5G
technology, expected to be used in IoT solutions.
2.5 Privacy and Legal Issues
The amount of information captured by IoT devices, along with advances in processing, capable of building
personal profiles, lead to questions of privacy which are one of the main concerns when it comes to
challenges presented by IoT technologies. In [46], 80% of IoT devices were found to violate the privacy
of personal information, such as name and date of birth. More than 80% failed to ask for passwords of
sufficient length and complexity and 60% had security vulnerabilities in their user interfaces [46].
Over the last few years reports made by government bodies address some of these challenges. In [16],
aspects of the European Union protection laws, in regards to IoT, are discussed. In America, the Federal
Trade Commission (FTC) also faces challenges of rights and legal aspects, publishing reports on security
and privacy [47].
Starting with personal data, under EU law, users of IoT devices will qualify as data subjects, which means
that if a device possesses personal information about that user, the individual in question will be classified
as a data subject even if the device does not belong to them. The stakeholders, which are classified
as data controllers, are responsible for processing and for the purpose of personal data. Examples of
stakeholders include device manufacturers, social media platforms, data hosting providers and third-party
application developers. The way the personal data is handled is also addressed under EU law, with the
consent of the data subject on how the information is processed a key aspect, but keeping in mind that
personal data process may be a necessity for the performance of the contract or application which the
data subject agreed to. Additionally, that same data process may be necessary for the legitimate interest
of the data controller, except when it conflicts with the fundamental rights of the data subject. The
fairness of data handling and processing is also addressed. Aspects like purpose limitations, which state
that the data collected must have specific, explicit and legitimate proposes are addressed. Furthermore,
data minimization aspects are mentioned as well, which discuss how the data should only be collected for
the necessary use, and not stored by default.
16
In [48] other points ranging from transparency, security, data subjects rights, processing of sensitive data
like health information and recommendations to stakeholders and device manufacturers are presented.
However, all these challenges expressed previously represent only a small part of the problems facing IoT
and the prospect of a connected world. For example, legal issues also encompass problems such as: cross
border data flows; data discrimination; the case of IoT in the aid of law enforcement and public safety,
which leads to questions of mass surveillance systems; the liability of IoT devices; and the proliferation of
legal actions in regards to IoT [20].
2.6 Security
There are an extensive number of security attacks, to which IoT is vulnerable, that can be categorized
by type. They are: physical attacks, network attacks, software attacks and encryption attacks. Table
2.5 shows some of these attacks. In the following section only what are considered the worst attacks in
accordance with [15] will be discussed.
Table 2.5: IoT attacks characterized by type [15].
Physical Attacks Network Attacks Software Attacks Encryption Attacks
Node Tampering Traffic Analysis Attacks Virus and Worms Side-channel Attacks
Malicious Code Attacks Sinkhole Attacks Spyware Cryptanalysis Attacks
Sleep Deprivation Attacks Denial of Service Trojan Social Horse Man in the Middle Attacks
Physical Damage Man in the Middle Attacks Malicious scripts
RF Interference Sybil Attacks Denial of Service
Starting with the physical attacks, the malicious code injection attack is considered one the worst. In this
type of attack, a new malicious code is uploaded to devices or gateways that contains a virus or a new
device is added to the network, already infected. The affected device can then send the wrong information
to other devices in the network and corrupt them. The attacker may gain access to the network and
even cause the service to become unavailable. Defenses to this type of attack are, among others, secure
authentication and booting, intrusion detection technology or a monitoring verification scheme, where
a monitoring node verifies others for abnormal behaviour and acts accordingly. Other types of attacks
found in this category are, for example, node tampering or direct physical damage, meaning devices that
have been altered, replaced or damaged respectively. These leave the information contained in that device
susceptible to being taken, such as encryption keys, routing tables, communication keys among others.
This leads to the device becoming a threat to the higher levels of the architecture.
In the network attacks section, the sinkhole attack is one of the most dangerous. In this attack a device is
compromised and used to commit the attack. The attack is made by faking the routing information so
that the other devices on the network think the compromised device is the closest to a base station or
17
gateway, redirecting the traffic to it, which can then result in altered or even dropped data. Defenses
include encryption and secure authentication so that the compromised node cannot enter the network,
or security measures added directly on the packets sent. Other types of attacks include man in the
middle attacks where an attacker intercepts data sent between nodes through the Internet, or Distributed
Denial-of-Service (DDoS) attacks where an attacker floods the network with traffic leaving it unavailable
or unusable.
Viruses, worms, spyware and adware are the worst and most common type of attack in the software section.
These attacks are made with malicious code, capable of replicating itself, and are normally transmitted by
emails or by downloading files from the Internet. Defenses against these types of attacks include anti-virus,
anti-spyware and anti-adware software as well as advanced encryption and web application firewalls.
In encryption attacks, the side-channel attack constitutes one of the most dangerous. This type of attack
uses cryptosystems, which are a series of cryptographic algorithms most commonly used in encryption,
to gain information about the system such as power management, time to perform tasks on the system,
partial or full plaintexts or even the cryptographic key. There are several types of side-channel attacks,
such as timing attacks, which measure how much time computations take to perform, or differential fault
analysis attacks, where secrets about the system can be uncovered through the introduction of faults in
computations. Defenses against this type of attack focus on advanced encryption techniques.
More attacks and their counter measures can be found in [15] and [49]. These attacks endanger the
perception and adoption of IoT, and there are already cases that have put IoT adoption into question due
to particular attack cases. In the smart home setting, for example, ways to control personal assistants
in the home through the use of ultrasounds imperceptible from humans [50] have been found. By using
normal voice commands and transforming them using programs, through the use of harmonics, that shift
the signal into frequencies above the human hearing range. These attacks gained the term of "dolphin
attack" because of the way dolphins use high pitched noises for echolocation. There are also worries
that IoT devices with cameras represent a way to introduce a camera into peoples homes [51]. Hardware
hack techniques, called flash memory attacks, exploit software bugs that not only expose the hacked
device but every other unit of that model [52]. Other, more personal and concerning problems are hacked
baby monitors [53], or being able to stop a pacemaker from working [54]. To face these problems the
Federal Trade Commission (FTC) and other organizations like the non-profit Internet of Things Security
Foundation (IoTSF) have provided reports [55] and studies [56] to alert to the possible dangers that IoT
may bring and the first steps to prevent them.
18
Chapter 3
Communication Technologies for the IoT
This chapter addresses some of the technologies which power the IoT. An overview of LPWAN technologies
is presented, followed by a comprehensive look and discussion on the various aspects of Sigfox and LoRa
technologies. Subsequently, a look at current hardware solutions for the smart home and some commercial
applications are presented.
19
3.1 Wireless Technologies
In IoT there is not a solution to fit every project and to find a technology that fills the necessary
requirements for it, a compromise between range, data rate and transmit power must be found. Some
of the most important design factors when choosing a wireless technology are [57]: data rate; range or
distance from the gateway; the environment; the need for encryption or authentication; power consumption;
the capacity of the network (number of connected devices); quality of service and reliability; the network
topology (star, mesh or other); one-way or two-way communications; licensed or unlicensed spectrum;
available integrated circuits, modules and equipment; the cost (design, manufacturing and internet access);
the development platform (if software is required); the type of internet access; and licensing conditions of
standards available.
There are various wireless technologies which can be used in IoT projects, such as: cellular technologies;
Wi-Fi; Bluetooth; Zigbee; Sigfox; LoRa; and Weightless. Figure 3.1 shows the relation between range and
bandwidth offered by several IoT technologies. LPWANs offer the greatest range with very low bandwidth,
which no other technology can match.
Figure 3.1: Range versus bandwidth [58].
There are several ways to classify these technologies, whether from short to long range [59] or from low to
high power. Table 3.1 represents nine technologies grouped from short range to long range, both LPWAN
and cellular.
Table 3.1: Short and long range IoT Technologies [59].
Fixed & Short Range Long Range Cellular Long Range LPWAN
Wi-Fi LTE-M Weightless
Bluetooth NB-IoT Sigfox
Zigbee EC-GSM LoRa
20
The most used Wi-Fi protocol, is the 802.11. It operates in the 2.4 GHz or 5GHz band and can handle
speeds from 300 Mbps to 1.3 Gbps, with ranges up to 100 meters depending on the environment. New
advancements in Wi-Fi continue to be made with the Wi-Fi Alliance planing to implement a program for
testing and certification of the 802.11ah protocol by 2018. This new protocol, nicknamed HaLow, is set to
compete with IoT technologies by using lower bandwidth and power with frequencies below the 1 GHz
band [60]. HaLow has a data rate of 150 kbps to 345 Mbps and can reach up to a kilometer with the
right antenna. Another Wi-Fi standard with focus on IoT settings is the 802.11af, which uses TV white
spaces or unused TV channels from 54 to 698 MHz. Stations use a database to confirm which channels
are available for transmission [57].
Bluetooth operates in the 2.4 GHz band. It has several different versions which offer different data rates,
power levels and range potentials. Normal data rate is 1 Mbps, with 2.1 Mbps and 3 Mbps possible [57].
It has three ranges, the first reaches up to 100 meters, the second 10 meters and the third only has a
reach of one meter. The last version, Bluetooth 5.0, offers a specific connection for long range, with the
worst case being 200 meters outdoors and 40 meters indoors [61].
Zigbee is a technology based on IEEE 802.15.5 standard for low rate wireless personal area networks. It
operates in the 2.4 GHz band but it also has the ability to be used in the sub 1 GHz bands. Data rates
in the 2.4 GHz band are 250 kbps, and in the sub 1 GHz are 20 kbps. It has a reach of 100 meters in
line-of-sight conditions [57].
LTE-M can be used to refer to all LTE based technologies for IoT. This includes LTE-Cat-1, LTE-Cat-0,
LTE-Cat-M1 and eMTC. These represent simplified versions of LTE, especially designed for low power
and low speed, with Cat-0 and Cat-1 solutions offering data rates of 1 Mbps and 10 Mbps respectively.
They have battery life up to ten years [62] and use licensed frequency bands. LTE IoT objects will use
SIM cards for security [63].
NB-IoT, which stands for Narrowband IoT, is a new radio technology being standardized by 3GPP. It uses
14 different frequency bands with 10 of them in the sub-GHz range [64]. It offers low complexity (close to
90% in comparison to Cat-1 [62]), low power consumption and long range, with data rates ranging from
100 kbps to 1 Mbps. This new standard can also be deployed in any LTE network as a software overlay
[57], and depending on traffic and coverage needs can achieve a battery life close to ten years.
EC-GSM which stands for Extended Coverage GSM, is an evolution of EGPRS towards IoT, with data
rate between 70 kbps and 240 kbps and like LTE-M and NB-IoT offers a battery life in the ten year range
[65]. This standard includes the latest enhancements to the GSM and EGPRS standards to support better
coverage, with the possibility of being deployed in existing GSM networks [62].
Last but not least, 5G technology is expected to play a bigger role in the IoT future but is still a few
years away, with its first specification released in the end of 2017 and a goal to complete Release 15 in
mid 2018 [66]. These new cellular IoT solutions although still a few years away from being deployed are
considered the biggest threat to LPWANs like Sigfox and LoRa.
21
3.2 Low Power Wide Area Networks
Before 2013 the LPWAN term did not exist[67]. LPWAN are technologies which focus on three main
aspects:
• Low power: few applications in IoT have the possibility to use a generator for power, so most devices
are powered by batteries. LPWAN devices have a battery life with ranges in 5 to 10 years.
• Long range: wireless networks need some kind of access point (gateway or base station). LPWANs
generally have ranges from 2 to 10 km in urban settings, offering more mobility in deployment and
the need for less gateways [68].
• Low data rates: data rates are generally lower than 5 kbps and therefore LPWANs only send small
packets of information ranging from 0 to 256 bytes [58].
One of the characteristics that separates LPWANs is the type of radio spectrum they use. Most operate in
the sub-GHz band which are Industrial, Scientific and Medical (ISM) bands. These are public, open but
regulated radio bands designed especially for use proposes other than telecommunications. The equipment
in these bands are subject to all interference generated by ISM applications. The most used bands for
LPWANs are generally: the 433 MHz and 902-928 MHz, in Asia; the 902-928 MHz in America; and the
863-870 MHz band in Europe. As the work focused on the 868 MHz band, only this band was reviewed.
The 863-870 MHz band has a power limitation of 25 mW (14 dBm) and a duty cycle of 0.1%. In the
868-868.6 MHz band there is an extension to a 1% duty cycle and in the 869.4-869.65 MHz band an
extension to 10% duty cycle and 500 mW (27 dBm) power is possible, which is normally used for downlink
messages [63].
Currently there is no adopted standard available in the LPWAN market [67] and they are usually defined
by the radio technology used [69]:
• Ultra-narrow Band (UNB): this type of technology uses modulation to achieve a very narrow
bandwidth, reaching greater distances. It only supports low data rates, with a typical payload
being around 12 bytes with its duration taking around 2s [63]. UNB LPWANs are only used in
applications where reliability and Quality of Service (QoS) are not very important.
• Narrowband: this type of technology offers the best compromise between QoS, capacity, cost and
network efficiency. With channel bandwidths around 12.5 kHz wide, they offer the best capacity for
uplink traffic of moderate sized data payloads from a large number of terminal devices;
• Wideband: the channel bandwidth of these technologies range from 500 kHz to over 1 MHz.
As this thesis focus on Sigfox and LoRa, a more in depth discussion of these technologies will be presented
in the following section. Another LPWAN technology is described, chosen for being an open standard.
22
Weightless is a LPWAN open wireless technology, from Weightless Special Interest Group, which includes
three specifications, each catering to a different LPWAN need. Weightless-W operates in the TV white
space, using channels 6 MHz wide in the 470-790 MHz band. It offers bi-directional transmission and the
data rate is between 1 kbps to 1 Mbps. It has a range of 5 km and a battery life around 3 to 5 years.
Weightless-P is a high performance bi-directional communication, using 12.5 kHz wide channels, that
operates in the 169, 433, 470, 780, 868, 915 and 923 MHz bands. Data rates can range from 200 bps to
100 kbps, with a typical range of about 2 km and a battery lifetime of 3 to 8 years. Weightless-N uses
UNB technology, operates in the 800-900 MHz band and only offers uplink transmissions. It has data
rates of 100 bps and has a typical range of 5 km. Intended for low cost applications, it reduces the power
consumption, with battery life up to 10 years [63] [57].
3.2.1 Sigfox
Sigfox has the objective to deploy a global cellular network with a focus only on IoT applications. It is
the most mature LPWAN technology, with their first network deployed in 2012 in France, and currently
present in 45 countries throughout the world [70]. In a move to become a more active player in the
development of IoT standards, Sigfox has joined ITU as a member in 2017 [71].
Technology Characteristics
Sigfox uses a proprietary technology offering low power, low data and long range solutions. It is both a
wireless technology and a network service. It is a UNB technology, works in the ISM band, and in Europe
uses 192 kHz, in the 868-868.2 MHz band [72]. In the rest of the world it uses the 902-928 MHz band,
with restrictions according to the regulations of the country.
Sigfox messages can be bi-directional. The uplink uses Binary Phase Shift Keying (BPSK) modulation
and has a data rate of 100 bps in Europe and 600 bps in America. Each message is 100 Hz wide, and is 0
to 12 bytes long, with the latter taking 2.08 seconds over the air [72]. Europe regulations only permit the
use of the 868 MHz band 1% of the time, which equates to 36 seconds air time in an hour, corresponding
to 140 messages, per day, per device, or roughly six messages per hour. Although messages that use fewer
than 12 bytes would be sent faster, making it possible to send more messages in a day, Sigfox does not
allow it. Sigfox uses the honor system to ensure the users comply with these limitations, saying that it is
the responsibility of the country’s telecommunications authorities to ensure the regulations are followed,
but also saying that if a user abuses the system they can blacklist devices [73]. All Sigfox messages are
sent in hexadecimal format. The Sigfox protocol overhead uses and additional 14 bytes making the Sigfox
frame 26 bytes in total. When a device sends a message, it uses a random frequency and then sends two
replicas on different frequencies and time. The maximum range achieved by Sigfox is in the thirty to fifty
kilometers in the countryside, or three to ten kilometers in an urban setting [17], with battery life usually
in the 10 year range.
23
The downlink uses G-Frequency Shift Keying (FSK) modulation with a data rate of 600 bps. The downlink
frequency is the frequency of the first uplink message plus a known delta, which puts the frequency
generally 1 MHz higher where the regulations on the band are 10% duty cycle. Downlink messages are
static eight bytes and only four, per device, per day are permitted. If, for example, more than four
messages are sent a best effort will be made to see if more can be received but devices which have not
received the four message daily limit will take precedent. The downside of Sigfox downlink messages is
that they can only be initiated by the devices following an uplink message. There is a twenty second
delay between the first frame and the reception window, that lasts for twenty five seconds maximum [70].
Following the reception of a downlink message, the device has to wait a minimum of six seconds before
sending another uplink message [18].
Architecture
Figure 3.2 presents the Sigfox architecture, which consists of devices, base stations, the Sigfox cloud and
the interfaces used to access the information on it. According to Sigfox [72], the architecture is divided
into two layers: the network equipment layer, and the support systems layer. The network equipment
layer includes the base stations and other equipment, such as antennas, and is responsible for receiving
the messages from the devices and sending them to the Sigfox support systems. The support systems
layer is the core network, or the Sigfox cloud. It is responsible for the processing of the messages sent
from the base stations. This layer also provides the entry point for different actors, which interact with
the Sigfox eco-system, such as Sigfox itself, Sigfox operators, channels and customers, to interact with the
system through web platforms, APIs and callbacks, as shown in the figure.
In the network equipment layer Sigfox implements a star topology where devices connect with base
stations, constantly monitoring for UNB signals. The devices are not connected to a single specific base
station unlike cellular protocols. All base stations near the device receive the message with the average
number of base stations being three, that means that three equal messages are sent to the Sigfox cloud.
The base stations are responsible for detection, demodulation and reporting the messages to the cloud.
Each base station has a direct point-to-point connection with the Sigfox cloud, through the public internet,
with the use of a VPN [72]. This connection uses DSL connectivity, 3G or 4G as a back-up, and when
neither is available, satellite connectivity can be used as an alternative.
The support system layer, present in figure 3.3 shows a detailed view of the Sigfox cloud. The back-end
servers are responsible for message processing, where all the messages that arrive at the cloud are sift
through with only one being stored on the network. The messages are stored in two locations: the
metadata storage to be used by the Sigfox web portal; and the customers message storage, so that the
customers can be able to retrieve them later via APIs or callbacks. It is in the cloud that the status of the
network is monitored and the base stations managed globally. This layer also includes critical modules
and features, such as the Business Support System (BSS) for ordering and billing and the Operations
Support System (OSS), as shown in figure 3.2. The latter are used for management functions, such as for
network inventory, service provisioning, and network configuration. These are all essential functions for
24
Figure 3.2: The Sigfox architecture.
the deployment, operation and monitoring of the network. Also on this layer are the tools to analyze the
data collected or generated by the network.
There are three ways to interact with the Sigfox cloud, as shown in figure 3.2:
• Internet: access to a web portal, through a web browser, made for end-users to access all Sigfox
cloud functions.
• APIs: access to the cloud functionality using APIs in pull mode, permitting the integration of some
of the Sigfox cloud functions in third party applications.
• Callbacks: enable the reception of new events automatically, such as messages in push mode, which
means getting data directly, without asking, by being notified by the Sigfox cloud when a new
messages comes in.
Access to these interfaces and tools depends on the type of profile the user has on the Sigfox cloud. For
example, a user can be only authorized to view messages, manage users and device fleets, see service maps
or check contracts. A distributor will be able to create contracts, while an operator will be able to access
radio planning tools and network monitoring solutions [74].
Callbacks can be custom made or use simplified bridges, with Sigfox currently supporting bridges for
Amazon AWS, Amazon AWS Kinesis, Microsoft Azure Event Hub and IoT Hub. There are three types
of callbacks: data, service and error [75]. Data callbacks can be uni-directional, offering three types
of channels: email, URL and batch-URL. Or they can be bi-directional, offering URL and batch-URL
channels.
Security
Sigfox implements security on all aspects of its architecture, from devices, to data, to radio and the cloud.
At the device level, devices do not have internet connectivity, which ensures that they cannot be hacked
through the internet. Each device has a different key unique to it, which guarantees that the compromise
25
Figure 3.3: A detailed view of the Sigfox cloud [72].
of one device has a limited impact on the system. Also, Sigfox devices have dedicated resistance to
interference available through secure elements, which are microcontrollers that secure applications and
their confidential data. Sigfox devices have three levels of security, with the device maker deciding which
to implement based on use case and sensitivity, which are:
• Medium: stores the security credentials on the device.
• High: stores the security credentials in a software based protected area.
• Very High: stores the security credentials in a secure element, which encrypts the data that is
transferred over the network. Only the device and the end-customer know the secret key and the
algorithm does not impact the size of the payload.
At the data level it has payload encryption as an option, based on Advanced Encryption Standard (AES).
It offers isolation of each part of the network and risk assessment, so that in the case of a hack, only a
minor segment of the network is impacted.
At the radio level, the Sigfox system uses authentication and relay avoidance measures, with the help of
sequence numbers on the messages, with optional anti-eavesdropping measures. Base stations although
26
connected to the internet also have numerous layers of protection. One of them is the ability of the base
station to only be able to boot from an OS built by Sigfox. In the same way an OS built by Sigfox can
only be run on a base station hardware [72].
At the cloud level, the servers are in secured certified data centers and each rack is protected by biometric
authentication for physical access. The cloud also offers corrupted message detection and has dedicated
solutions against DoS and DDoS attacks, among others.
3.2.2 LoRa
LoRa (LOng RAnge) technology was designed and developed in 2009 by Cycleo [76], and later acquired
and patented by Semtech in 2012 [77]. It is an established LPWAN technology, focused on IoT applications.
Semtech expected it to be present in more than 60 countries around the world at the end of 2017 [78].
LoRa has two distinct aspects. The first is the LoRa physical layer and the second, an open MAC layer
protocol called LoRaWAN, that provides access to the LoRa architecture [79]. To talk about LoRa
one has to address the LoRaWAN protocol, an open standard communication, and the proposed MAC
layer defined by the LoRa Alliance consortium, a non-profit association led by IBM, Actility, Semtech,
Microship and many other members, which drives the advancement of LoRa and the LoRaWAN protocol
[80]. However, LoRa can use other MAC layers protocols.
Technology Characteristics
LoRa is a proprietary technology that uses modulation based on Chirp Spread Spectrum (CSS) [18]. It
is a wideband technology and works in the ISM band. The most used frequencies are: in the USA the
915 MHz band, in Europe the 868 MHz band, and in Asia the 470 MHz band. A LoRa radio has four
configuration parameters, which determine the energy consumption, transmission range and resilience to
noise, which are [81]: carrier frequency, spreading factor, bandwidth, and coding rate.
Those parameters change the way the LoRa/LoRaWAN payloads are transmitted. LoRaWAN can use
channels with a bandwidth of either 125, 250 or 500 kHz, depending on the region or the frequency plan.
The data rate ranges from 250 bps to 27 kbps using a spreading factor of seven and a 500 kHz channel
[65] or, for example, 300 bps to 5 kbps using a 125 kHz channel [82]. LoRaWAN supports data payloads
between 19 to 250 bytes and uses a protocol overhead of 12 bytes [18]. It also offers ranges from two to
five kilometers in urban areas, and fifteen to forty five kilometers in rural areas, with battery life in the 10
year range.
LoRaWAN defines three types of classes for devices: class A, class B and class C. While the implementation
of class A is mandatory, class B and C are optional. In LoRaWAN 1.0 specification only the Class A
devices are supported, but at the end of 2017 the LoRa Alliance released the LoRaWAN 1.1 specification
which supports Class B devices. Class C is not currently supported. Figure 3.4 shows the three classes
with their major differences being the trade off between latency and power consumption [82] [80].
27
Class A, for "All", supports bi-directional communication, where the devices can initiate the data
transmission at any time. After the transmission, the device enters a listening state where it will open,
at minimum, two listening windows waiting for acknowledgment, some type of command, or a data
packet from the network server. If nothing is received, the next opportunity will be after the next uplink
transmission. This class has the lowest power consumption and a high latency.
Class B, for "Beacon", allows for a bi-directional link with scheduled listening time-slots, introduced
to decouple uplink and downlink transmissions. Devices synchronize with the network server by means
of beacon packets, shown as "BCN" in figure 3.4, which are broadcasted on a regular basis by Class B
gateways. The devices can then receive downlink data, or command packets in specific time windows,
irrespective of the uplink traffic. This class also provides support for fallback to class A, in case of battery
constraint operation models. It has medium power consumption and low latency.
Class C, for "Continuous", allows the device to be always listening for data packets except during
transmission. These devices are used for applications that have sufficient power available or are connected
to the grid and thus do not need to minimize reception time windows. Class C devices will listen with
"RX2" windows parameters as often as possible, only stopping for either sending or receiving on "RX1",
as shown on figure 3.4. They open a short window on "RX2" parameters between the end of the uplink
transmission and the beginning of the "RX1" reception window, after which they switch to "RX2"
reception parameters, as soon as the window is closed. The "RX2" reception window remains open until
the end-device has to send another uplink message. This class has the highest power consumption and the
lowest latency.
Figure 3.4: LoRaWAN device classes [79].
28
Architecture
Figure 3.5 presents the LoRa architecture. The devices are connected to one or many gateways. LoRa
uses star topology, where the gateways relay messages between devices and a network server [79]. The
communication between the devices and the gateways uses different spread out frequency channels and
data rates, through a trade-off between the communication range and the message duration. A standard
LoRa device can decode only one spreading factor modulation over a single frequency [81]. The gateways
forward the payload information to their associated network server and act as a bridge, totally transparent
to the end devices. They are connected to the network server through Ethernet, 3G, 4G, Wi-Fi or satellite
connection. At the base of all gateways sits a LoRa concentrator, which is a multi-channel demodulator,
able to decode all versions (obtained by varying the SF parameter) of LoRa modulation, on several
frequencies at the same time [83]. The LoRa gateways are capable of decoding up to 9 channels at the
same time, with channels being identified by a specific sub-band and spreading factor [80] [82].
The network server is responsible for decoding the messages, performing security checks, filtering duplicate
and unwanted packets and for replying to the end devices by choosing one of the gateways in range [80].
It also enables remote management of gateway modules, device level management and enhances security
through a web service which the end user can connect via the internet [81]. The application interface may
be provided by the network server, or the information can be sent from the network server to a custom
IT solution developed by the costumer, or an IoT platform. The network server must be provided by
third-party companies as Semtech does not have one.
Figure 3.5: The LoRa architecture.
Security
Devices using LoRaWAN have two ways of joining a network server: either through Over The Air
Activation (OTAA) or Activation By Personalization (ABP) [84]. Using OTAA, each device is deployed
with a unique 128-bit app key "AppKey" which is used when the device sends a join-request message.
The message is not encrypted, but signed using this "AppKey". The message comes with: an "AppEUI"
value, unique to the owner of the device; a "DevEUI" value, globally unique identifier for the device; and
a "DevNonce", which is a randomly generated two byte value. The network server then checks the values
and, if valid, responds with a join-accept message.
29
In ABP, the devices are shipped with the device address value "DevAddr", and both the network session
value "NwkSKey" and "AppKey", which are unique to it. As the devices already have the information
and keys they need, they can begin communicating with the network server without the need for join
messages. As the "NwkSKey" and "AppKey" session keys are only known by the network server and the
device, there should be no way for other devices, or a man-in-the-middle attack, to recover the data. The
encryption of messages is made using AES128. LoRa devices also feature up and down message counters
which are maintained by the device and the network server, and these counters never repeat.
3.2.3 Differences between Sigfox and LoRa
Table 3.2 presents some the differences between the most important technical aspects of both technologies.
As LoRa only represents the physical layer, the differences to Sigfox were made with LoRa using LoRaWAN.
Table 3.2: Differences between Sigfox and LoRa/LoRaWAN.
Sigfox LoRa/LoRaWAN
Frequency868 MHz (EU)
902-928 MHz (USA, AS)
868 MHz (EU)
915MHz (USA), 470 MHz (AS)
Range3 - 10 km (urban)
30 - 50 km (rural)
2 - 5 km (urban)
15 - 45 km (rural)
Data Rates 100 bps (Up), 600 bps (Down) 250 bps - 27 kbps
Topology STAR STAR
Modulation DBPSK (Up), GFSK (Down) CSS
Payload 12 Bytes (Up), 8 Bytes (Down) 19 - 250 Bytes
Power levels 0 - 14 dBm 0 - 14 dBm
Battery Life 10 years 10 years
Messages/Day 140 (Up), 4 (Down) Unlimited
Bandwidth 100 Hz (Up), 1.5 kHz (Down) 125 kHz, 250 kHz, 500 kHz
Both technologies use the same frequency band in Europe and their ranges are very similar. Sigfox uses
ultra-narrowband technology, with very small bandwidth. LoRa, on the other hand, uses modulation
based on Chirp Spread Spectrum (CSS), with a wider band [85].
The technologies also differ in the amount of messages that can be sent in the up and downlink transmissions,
as well as the size of the payload. Therefore, Sigfox is better suited for applications that do not require
constant exchange of messages, but only a handful of messages per day. LoRa has more leverage in the
amount of messages it can send daily. For example, it does not send two replicas of the same message every
time one is sent. It can manage higher transmission speeds, which equate to less time on air, therefore,
account for even more messages. As referenced before, Sigfox takes 2.08 seconds to send a twelve byte
30
message but, even if only a six byte message is sent, which would takes less time, Sigfox continues to only
allow the 140 daily limit, while on LoRa, different sized messages will have an impact on the air time and
consequently on the number of messages that can be sent.
Another difference is in the base stations from Sigfox and the gateways from LoRa. Sigfox deploys and
manages its own base stations, while LoRa gateways can be bought or made. LoRa gateways can be
found at varying price levels with some costing 1600 e[86], others 800 e[86], or even 150 e[87], with the
use of a raspberry pi.
There are also significant differences in their business model. With Sigfox, the company owns all of its
technology from the back-end data and cloud servers to the device software. Sigfox partners with other
companies in each country to build and operate the network infrastructure, with existing cell towers and
placements being used to minimize cost. Additionally, only one Sigfox network can be deployed in an
area, because the company has exclusive arrangements with its network operators [85]. However, in some
cases, Sigfox itself deploys the network and acts as the network operator.
LoRa uses a different strategy. Semtech leaves the development of network products and services to
third party companies such as Cisco, Actility and IBM [88]. Just like SigFox, the LoRa Alliance wants
network operators to deploy the LoRa network, but they also want private companies and start-ups to
do it. LoRaWAN is an open standard that can have two types of networks, the private and the public.
The private is operated by private individuals, for private asset tracking, wireless sensor networks or for
obtaining an individually catered home automation network. It can also serve for companies in industrial
context for networks related to the industrial IoT segment. The public LoRaWAN network is where mobile
networks operators own the network infrastructure and offer it as a service to their clients [18]. According
to the LoRa Alliance deploying a LoRa network from scratch costs about the same as upgrading a mobile
network with software to support NB-IoT [89].
Regarding devices, both technologies also differ. Sigfox does not design any hardware, opting instead to
share their design and license its software to vendors, such as, Texas Instruments, Samsung, Telit and
Axcem. It uses a certification scheme on the hardware, called "SIGFOX Ready", with devices getting
sorted by class 0, 1, 2 or 3 based on their radiation performance rating [90]. More information on Sigfox
certification and devices classification can be found in [91]. This type of model means that is necessary to
work directly with Sigfox because there is no other option.
LoRa technology is free to use, but Semtech is the sole company that designs and fabricates the LoRa
transceiver chips for the end devices, as well as the concentrator chips for the gateways. However, any
hardware or gateway manufacturer can join the LoRa Alliance and build a module or gateway that
conforms with the LoRa specifications. So, although the LoRa ecosystem itself is open, it has a closed
element.
31
3.3 State of the Art
Through the Sigfox partner solutions [92] site, Sigfox offers transceivers, System on a Chip (SoC), modules,
devices and developer kits. Five transceivers are currently available from Texas Instruments and Silicon
Labs. They are: the AX5043; S2-LP; CC1120; CC112; and the SI446X transceiver family. These
transceivers are all capable of working in the ISM frequency bands at 433, 868 and 902 MHz and at
additional programmable frequencies. The prices vary between the 0.5 to 5 erange. Also available at the
Sigfox site are 10 system-on-chip, 54 modules, 374 devices and 66 developer kits.
For LoRa, Semtech currently has five transceivers available. They are: the SX1272 and SX1273 for
frequencies between 860-1000 MHz; the SX1276, for 137-1020 MHz; the SX1277, for 137-1020 MHz; the
SX1278, for 137-525 MHz; the SX1279, for 137-960 MHz; and the SX1268, the SX1262 and the SX1261
for 150-960MHz [93]. These devices are currently all within the 4 to 10 eprice range. Also available are
two chips for LoRa gateways: the SX1308 for indoor gateways and SX1301 for outdoor gateways.
Lora deployment has continued to advance as networks are set up all over the world. In Korea and the
Netherlands, the telecom companies responsible for the deployment of LoRa network in their respective
countries were both members of the LoRa Alliance [94]. In London The Things Network (TTN) launched
fifty LoRaWAN base stations free to use across the city for IoT devices [95].
Because cellular IoT technologies are still in their early stages of development products which use these
technologies are hard to find. However, for NB-IoT the first roll-outs of the technology are expected for
2018 [96]. In 2017, u-blox, a Swiss company in the natural gas market announced their successful field
trials on their NB-IoT network [97]. At the start of 2018 Cisco was the first company to launch a global
NB-IoT platform solution that, in conjunction to NB-IoT, will also allow for enterprises to manage cellular
devices [98].
IoT is also seen entering commercial areas. For example, the Amazon Go [99] is a new generation of shop
where through the use of sensors, machine learning, artificial intelligence and computer vision, shoppers
can enter the store, take the products they want and leave, effectively eliminating queues. After leaving,
the user will be notified of the purchase and the price of the products will be deducted from their account.
One of the ways that the IoT has found a way into the consumer lifestyle and by extension its home is
through smartphones, particularly smart assistants. The development of virtual assistants like Google
Now, Amazon Alexa, Apple Siri, and Microsoft Cortana, coupled with push toward artificial intelligence
by tech companies, will prove an important step for a more cohesive IoT world. Some products, like
Google Home [100] and Amazon Echo [101] partnered with the smart assistant Alexa have already entered
the smart home setting. Advances with these smart assistants, in conjunction with IoT products, can
already open and close doors. Such is the case for the Amazon key [102], which opens doors remotely
through the installation of a smart lock on the door, with a series of smart cameras that let couriers open
the door with a request, so they can drop packages inside the house when a costumer is not home.
32
Other products for the smart home, such as the door bird [103] device are already available. Like the
Amazon key, this is a smart lock device, which alerts the user through his or hers smartphone when there
is someone at the door, enabling them to see the person, talk to them and open the door from anywhere
in the world. It uses Wi-Fi technology, when in the home, and 3G/4G networks, when anywhere else in
the world. The Eve Degree [104] is a device which lets the user see the current temperature and humidity
in the home and comes with a mobile application for easy access to the information. There are also smart
homes built entirely from the ground up, with a focus on mobility and the IoT. Kasita [105] is a compact
home that enables the user to adjust every aspect of it, using voice commands from smart assistants.
Sigfox devices for the smart home are also available. The Sens’it 2.0 [106] device can be used for reading
temperature and humidity, or ambient light in a home. Another product from Sigfox, the "bttn" [107], is
a small programmable device which lets the user order services or products with just one push. Sigfox has
also partnered with Louis Vuitton on a luggage tracker [108].
LoRa also has devices with focus on the smart home. Company Eddy Home offers a water monitoring
and consumption tracking system [109] based on LoRa technology. It offers a custom dashboard that lets
users see their home water usage and statistics, either through a smart device, with the eddy home app,
or using a computer with a browser.
Questions of security and privacy continue to dominate the IoT. One solution which is currently being
studied to solve these problems is Blockchain. It can already be seen entering solutions like the IBM
Watson IoT Platform [110]. Applications of this technology can already be seen entering the smart home
also. An Australian company, Telestra, has started to use blockchain to secure smart home systems by
storing biometric and authentication data on a private blockchain. This blockchain is then capable of
verifying the identity of the IoT devices and of the people interacting with them, to prevent compromised
devices from usurping the platform [111].
33
34
Chapter 4
Smart Home Project
In this chapter, the smart home system is detailed. First, the experiences with Sigfox and the various
modules and sensors are presented, ending with the steps to synchronize the devices with various IoT
platforms. Second, the LoRa experiences in setting up the gateway and modules and also the steps to
synchronize them with their own network services and IoT platforms are detailed.
35
4.1 Smart Home Architecture
There were two possible ways considered to implement a smart home IoT architecture solution. Presented
in figure 4.1 and figure 4.2 are two general architectures which could be used for the desired result of the
smart home project.
Figure 4.1: Smart home architecture solution using only cloud services.
On the first solution, present in figure 4.1, the devices would send the information to their respective
cloud services. That information could be accessed in two ways: by a custom smart home and smartphone
application; or by a web browser and a smartphone application. The custom smart home application would
be an embedded central computer system in the home, usually referred to as a hub. This system would
gather all information from the devices, sent from the cloud, and present it on specific home consoles,
which can be embedded on walls, or in tablets with custom software. The custom smart home system
could also have a smartphone companion application for users to download, so they could access home
information on the go. The other possibility would be to access the device information from the cloud
service using a web portal with a web browser, through the use of a personal computer, smartphone or
tablet, or through a smartphone application, made by the cloud service itself.
Figure 4.2: Smart home architecture solution using IoT platforms.
36
In the second solution, present in figure 4.2, the devices would send the information to their respective
cloud services also, but now that information would be redirected to an IoT platform. The information
could then be accessed the same way as the previous solution, by a custom smart home application or a
web browser. The only difference being that IoT platforms have a better user interface and generally are
more user friendly. This means, for example, that a custom smart home application, in this case, would
only need to present the information sent from the platform as opposed to having a custom software, built
specifically for presenting it. The IoT platform could also have a smartphone application specific for it.
In the case of Sigfox, the cloud has a very basic and not user friendly interface, because it is not meant
to be used as a platform, and the options for device analytics are limited. So, the better solution would
be to use the architecture in figure 4.2. This way the information from the devices could be parsed and
better presented by the IoT platforms, offering more statistics and history about the home devices, for a
better understanding of their home use.
In the case of LoRa, because some of the network servers also serve as IoT platforms, the better solution,
would be to implement the architecture in figure 4.1.
4.2 Sigfox Solution
For the Sigfox smart home solution, the architecture used in this work is presented in figure 4.3. To
achieve it, several steps were taken.
Figure 4.3: Proposed smart home architecture using Sigfox technology.
The first step was to make and program a prototype using Sigfox technology. The second was to register
the prototype with the Sigfox cloud and successfully receive the Sigfox messages at the back-end. The
third was to synchronize the prototype with several IoT platforms to see which one would be better suited
for the smart home architecture designed. The fourth, and last, was to build a dashboard, so that a user
could access it by way of a web browser or smartphone application, as shown in figure 4.3.
37
Three hardware developer kit modules were used. The Telecom Design TD1208 Evaluation Board Kit [112],
which was given by Narrownet, the Sigfox operator in Portugal. The SmartEverything [113] evaluation
board, and finally an Arduino UNO R3 equipped with a shield and Sigfox module from Cooking Hacks
[114].
The modules used the Arduino IDE software with C programming language, aside from the TD1208
Evaluation Board Kit. Programs using Arduino are generally called sketches. They use two basic functions:
the setup, and loop functions. The setup function is called once upon the device turning on or resetting. It
is mainly used for initiating variables, addressing input and output pin modes and other possible libraries
needed in the program. The loop function, as its name implies, is a continuous loop, only stopping by
turning off or resetting the device.
4.2.1 TD1208 Evaluation Board
This kit from Telecom Design was used in the first experiences with the Sigfox network and IoT platforms.
It includes a breakout board with the Sigfox module, a twenty centimeter 868 MHz antenna, a FTDI serial
cable, one year subscription to the Sigfox network and one year access to the TD developer back-end,
which gives access to a Telecom Design IoT platform where the Sigfox messages can be visualized.
This board works by sending Sigfox messages with the use of AT commands from a command-line interface.
"AT" commands, short for attention, are simple instructions used to communicate and control a modem.
They are the lowest level of interaction available with a Sigfox module, except when using a Software
Development Kit.
As the board was already registered at the Sigfox back-end only the token for it, which is a one
year Sigfox contract, had to be renewed. After sending the first Sigfox message with the command
AT$SS=414243444546, corresponding to ABCDEF, it was possible to confirm on the Sigfox back-end that
the messages had been received.
To test the callback feature, an email callback was created. It was necessary to select the device name at
the Sigfox back-end, and choose the create NEW callback option. In that callback sub-menu it is possible
to select between a custom or dedicated bridge callback. Figure 4.4 presents the options necessary for an
email callback. The email recipient, the subject and the body of the message were filled as the figure
shows. The time sent from Sigfox is represented in a Unix time stamp.
The second data callback, was made to the Carriots platform [115]. This type of callback has an URL
channel, with the HTTP method selected as POST. After creating a Carriots account, an URL address
was available to use, which was filled on the designated field for the callback, with the respective API key
generated on the platform. This type of callback is further explained in the section 4.2.4.
38
Figure 4.4: View of a Sigfox email callback.
4.2.2 SmartEverything Board
The SmartEverything evaluation board comes with a Sigfox module, has Bluetooth and NFC connectivity,
a GPS receiver, a cryptography authentication chip, an absolute barometer and altimeter, proximity and
ambient light sensors, a 3D accelerometer, a 3D gyroscope, a 3D magnetometer, and a temperature and
humidity sensor. The board comes with a one year subscription to the Sigfox network.
After installing the necessary drivers, board support and libraries in the Arduino IDE, the board was not
recognized by the software. Searching for an answer through forums and help guides proved unsuccessful,
although the problem seemed to be related to the fact that the computer used was a Mackintosh. However,
this could not be confirmed. When the use of this board was beginning to seen impossible a beta version
of the Arduino IDE was made available to solve this problem. This software version solved the problem of
the board being recognized by the computer, but introduced another one. The software was now unable
to create new sketches, rendering it useless. After installing the old version of the Arduino software, the
board was now recognized and sketches could be created.
After solving the problem of the installation, all sensors of the board were tested, with the GPS receiver
taking a long time to locate the device. To test the Sigfox network the board had to be registered at the
Sigfox back-end. After registering, the Sigfox connection was tested as well. Other experiments were
conducted by using sketches found for the board, for example, one which sent a test message every ten
minutes to the Sigfox network [116]. Further experiments with this board were not possible because the
token expired.
39
4.2.3 Sigfox Radio Shield for Arduino
The Arduino UNO R3 was equipped with a shield and Sigfox module from Cooking Hacks. It was the
board where most Sigfox experiments were conducted and the prototype device used for the smart home
system. With the Arduino board, several sensors were used, such as: two temperature and humidity
sensors (model DHT11 and SHT31); two rain detection sensors (no visible markings on the model); a
moisture sensor (model IM121017001); two PIR motion sensors (model PTR004226); and an adapter
board designed for the evaluation of an accelerometer (model LIS344ALH).
All sensors were tested and for each one the necessary libraries were installed, with some getting multiple
trials with different ones. The DHT11 sensor presents the temperature and humidity. The rain detection
sensors present three situations: no rain, a rain warning or a flood warning. The moisture sensor, shown in
figure 4.5a, returns a value for the moisture content in the soil. The two motion sensors detect movement
up to seven meters. The SHT31 sensor also presented temperature and humidity values. And lastly,
several tries were made to test the accelerometer.
The sensor chosen for the smart home system was the SHT31 temperature and humidity sensor. First the
Cooking Hacks libraries for the Arduino software were installed. Upon starting to use the module it was
found that the software did not allow to upload sketches, citing errors in the upload progress. The solution
was found by removing the Sigfox module, uploading the sketch to the board, and finally connecting the
Sigfox module again. This had to be done every time that a new sketch had to be uploaded.
In figure 4.5b the Arduino board can be seen connected to the shield and Sigfox module, with the SHT31
sensor connected with the help of a breadboard. A new program was created for this prototype, presented
in Annex A, which only used the loop function of the Arduino, a measure taken to prevent errors from
disconnecting and connecting the Sigfox module to upload sketches.
The sketch created first initialized the temperature sensor followed by the Sigfox module; second, the
temperature and humidity values are retrieved and sent, in a 8 byte message, 4 bytes for the temperature
and 4 for the humidity, to the Sigfox back-end; and third, a delay of twenty minutes is issued. Figure 4.6
shows the message received at the Sigfox back-end with a custom payload display, created for decoding
the hexadecimal data. To change the payload display data one has to select the Device Type at the Sigfox
back-end and edit its information. In the payload parsing field it was necessary to chose the custom
grammar option and input the custom configuration for the data.
As the Arduino is not a very power efficient board, a sleep library called "Narcoleptic" [117] was added to
the program to see if the board could sustain itself for longer periods of time, powered only by batteries.
The "Narcoleptic" library uses features from the Arduino microcontroller and reduces power consumption.
It is best used when the device is in a stand-by mode, to simulate a power-off state. Two trials were
conducted, shown in figure 4.7. The first used a 9V battery and the second an eight 1.5V AA battery
holder.
40
(a) Moisture sensor experiment. (b) Temperature and humidity sensor experiment.
Figure 4.5: Experiments conducted on the moisture and temperature sensors.
Figure 4.6: Example of a Sigfox message at the back-end.
An email callback was set up to ensure that the messages were being received without having to check
the Sigfox back-end every time a new sketch was uploaded. Another sketch was created which made
use of the PIR sensor. The sketch continuously searched for movement and, if detected, sent a message
to the Sigfox back-end. A simple downlink experiment was also conducted. To make it, in the Device
Type configurations, the device was edited to allow a direct downlink from Sigfox. The downlink message
contained the time and RSSI values.
(a) With a 9V battery. (b) With an eight 1.5V AA battery holder.
Figure 4.7: Battery tests conducted on the prototype.
41
4.2.4 Sigfox IoT Platforms
To complete the smart home architecture defined in figure 4.3, it was necessary to synchronize the devices
with IoT platforms, through the use of Sigfox callbacks. Several platforms were considered and seven
were tested with the prototype Arduino device. They were: the Cloudthing [118]; the Tago [119]; the Wia
[120]; the Thinger [121]; the Databoom [122]; the Amazon AWS [123]; and the Microsoft Azure [33]. In
this section only the two platforms which had the most different implementation and were considered the
most important will be addressed. The rest of the platform experiments are explained in the next chapter,
along with a discussion on some of their implementation difficulties.
To use the Thinger platform, there were three steps taken: the first was to create the data bucket, which
stores the received information from Sigfox, and an access token, necessary for the data to be accepted by
the platform; the second to create the Sigfox callback with the necessary authentication to the platform;
and the third to create the dashboard at the platform for easy access to the prototype information.
For the first step:
• A data bucket was created in the Buckets section of the platform, and a bucket ID, name, and
description were filled. A switch to enable the possibility to write data on the bucket had to be
activated, and the Data Source had to be set as From Write Call, because the Sigfox device is not
connected to the platform but pushes the messages using the callback feature.
• In the Access Tokens section, when a new token is created, the token ID, and name were filled. The
access token enables access to the data bucket and to write operations. A switch was enabled to
activate the token, and at the end the Token permissions needed to be granted to the data bucket
created previously. After creating the token, a value for it will be generated.
For the second step:
• At the Sigfox back-end, a custom data callback was created, using a custom payload configuration
which already parsed the temperature and humidity sent from the device. The callback is shown in
figure 4.8a. The URL pattern is configured according to the user and bucket ID from the platform
account. The HTTP Method must be set to POST, and the Headers option must contain the
text Authorization in the header field, and the value field must be Bearer {access_token}, where
the token is the one generated previously in the platform. The body of the callback is in JSON
(JavaScript Object Notation) format, shown in figure 4.8b and contains some information of the
device and the Sigfox base station that received the message.
The third was to build a dashboard using the values on the data bucket to create widgets for each message
field.
42
(a) Data callback example using URL channel. (b) JSON data.
Figure 4.8: Callback configuration for the Thinger Platform.
Another platform tested was the Amazon AWS. This type of platform uses a simplified bridge callback,
dedicated to its service. The platform configuration had three steps. The first was to create the Sigfox
callback choosing the AWS IoT option. The second was to create a Stack in the AWS Cloud Formation
console, where several parameters are generated which are then inserted in the callback. The third
was to create an AWS IoT Rule in the Amazon cloud, responsible for storing the data into an Amazon
DynamoDB table.
After creating the AWS IoT callback at the Sigfox back-end, the Config method must be left as
CROSS_ACCOUNT and the External ID must be saved to use later at the platform.
The callback has a link that redirects to the Amazon CloudFormation platform where the Stack name,
the AWSAccountId, the External Id, which was obtained in the callback, the Region and the Topic Name
were filled, finalizing the stack construction.
Then it was necessary to obtain the stack values for the ARNRole, Region and Topic key. This values
are then inserted in their respective fields at the Sigfox AWS callback as well as the JSON body, closely
relating the one from Thinger shown in figure 4.8b. However, the data field was sent in hexadecimal,
because AWS does not support custom payload configurations. With this two steps it is possible to see if
the callback was set successfully by confirming it at the message section in the Sigfox back-end.
The last step was to create an AWS IoT Rule to store the data received in a Amazon DynamoDB table.
After going to the DynamoDB section a new table was created. There, a name, partition and sort key
are also created. When the table was finished, a new IoT Rule was created where the message source,
DynamoDB table, Hash and Range keys are filled. The latter ones are used for ordering the Sigfox
messages at the platform.
Further experiments to parse the information in the platform were conducted. Amazon AWS also has a
mobile application where it is possible to access some limited information about the devices connected to
it.
43
4.3 LoRa Solution
For the Lora smart home solution, the architecture used was different from Sigfox, and is presented in
figure 4.9.
Figure 4.9: Proposed smart home architecture using LoRa technology.
To bring this architecture to fruition, a prototype device was needed using LoRa technology. Next a
gateway had to be acquired to receive the LoRa messages from the device and to redirect them to the
chosen LoRa network server. There are several companies which offer LoRa network services, with some
offering IoT platform capabilities as well. Lastly, the information would be accessed through the network
server portal, using a web browser accessed with a computer, tablet or smartphone. The network server
could also have a dedicated smartphone application.
For this solution the first step was to buy a LoRa gateway device, which was necessary, as the LoRa
Network does not deploy their own gateways like Sigfox. The solution was found to be the Dragino LoRa
gateway kit [124]. This kit came with a LoRa Gateway-LG01 P, shown in figure 4.10a, which can have 3G
and 4G module installed. The kit also had two Arduino UNOs, a LoRa shield, shown in figure 4.10b, a
LoRa/GPS shield, three 868 MHz antennas, a flame sensor, an ultrasonic sensor, a photosensitive sensor,
a buzzer, a relay, and a temperature and humidity sensor.
The LoRa technology was tested using two different protocols, the RadioHead and the LoRaWAN. The
former was the recommended protocol, by the Dragino kit, to test the basic LoRa technology connection.
The latter is the most used protocol with LoRa technology. For these LoRa experiments all modules used
the Arduino IDE software program, including the LoRa gateway which also had a web browser interface.
All the code used in the LoRa solution was found at [125].
44
(a) The Dragino LG01 Gateway [126]. (b) The Arduino LoRa Shield.
Figure 4.10: Dragino devices.
4.3.1 RadioHead Protocol
For the experiments using this protocol the LG01 gateway was used with the Arduino LoRa shield, and
one DHT11 temperature and humidity sensor. The gateway comes pre-configured as a Wi-Fi access point
by default. When turned on, it generates an unsecured hotspot in its vicinity, where it is possible to
connect to it. To test the gateway, first the necessary boards were installed.
Next, a way to test the LoRa connection between the gateway and the Arduino with LoRa shield was
conducted. For this experiment the RadioHead library [127] was used. A sketch for the Arduino LoRa
shield was uploaded, which sent a message to the gateway and then waited for a response. If successful it
shows the RSSI and a response to its message. If no response is received the program would remain in
loop asking if the LoRa server was running. The sketch for the gateway was also uploaded which waited
for the message from the LoRa shield, and if successful showed the message received, the RSSI, and sent
a message back. The RadioHead library used by both sketches utilized the same frequency (868 MHz),
bandwidth (125 kHz), coding rate (4/5) and spreading factor 7 (128 chips/symbol).
The next experiment performed with the RadioHead library was to synchronize the LoRa shield and
gateway with an IoT Platform. The recommended platform, by the Dragino company, was the ThingSpeak
[128], which is an open platform that supports LoRa devices. The gateway would have to be configured
to be able to join the home Wi-Fi network in order to be able to send the information to the platform.
There are several ways to configure the gateway to access the internet, and the Wi-Fi client mode was
used. To configure it, it was necessary to access the gateway web interface, presented with all its options,
in a compressed view, in figure 4.11. To configure the gateway in Wi-Fi client mode, it was necessary to
select the Network tab and disable the Wi-Fi access point and Wi-Fi Mesh Network, enable DHCP server
in its LAN port and enable internet access via Wi-Fi client mode. Then the necessary SSID, password
and encryption for the home network were filled.
45
Figure 4.11: A compressed view of the LG01 gateway interface.
With the gateway configured it was now necessary to create an account at the ThingSpeak platform. A
dashboard at the platform was created, with fields for temperature and humidity, that generate a specific
ID and API key. The ThingSpeak library was then installed in the Arduino IDE software. The DHT11
sensor was connected to the LoRa shield and a sketch was upload to the Arduino. In the sketch, the sensor
reads the temperature and humidity values, sends the data and waits for a possible acknowledgement
from the gateway which has to have the correct LoRa node ID. Just as the previous experiment this data
is sent with the same LoRa radio configurations as the gateway. The sketch was changed so that instead
of the thirty seconds interval between messages, a twenty minute interval was used.
In the gateway sketch, the ID channel number and API key, generated in the ThingSpeak, were filled.
The sketch listens for data sent from the LoRa node, checks if the LoRa node ID is correct, sends an
acknowledgment reply to the node and lastly sends the information to the platform. Figure 4.12 shows
the gateway, in Wi-Fi client mode, and the LoRa shield with the DHT11 sensor.
46
(a) Dragino gateway in Wi-Fi Client mode. (b) LoRa shield with DHT11 sensor.
Figure 4.12: The ThingSpeak Platform experiment.
4.3.2 LoRaWAN Protocol
For the LoRaWAN protocol, the LG01 gateway was used with both the Arduino LoRa shield and the
Arduino LoRa/GPS shield. For these experiments the devices were set up with the "The Things Network"
(TTN) network service [129], which allows for the management of both the gateway and the device but it
did not have dashboard capabilities. After creating an account at the platform it was necessary to both
register the gateway and the device. In the gateway console page, the ID, which is an eight byte hex value,
had to be created. The MAC address that comes on the underside of the gateway was used for it, but as
the address only has a six bytes, a suffix was added. It was also necessary to select the packet forwarder
option of the gateway and upload the sketch for it. But before the sketch could be uploaded, the gateway
had to be configured to support the LoRaWAN protocol.
First, the configurations for the LoRa radio were made, such as the frequency channel, the spreading
factor, the coding rate and the signal bandwidth which had to be the configured to match the ones from
the Arduino LoRa shield. The following parameters were set: frequency of 868.1 MHz; spreading factor
seven (SF7); coding rate of 4/5; signal bandwidth of 125 kHz; and preamble length set at eight. Second,
the LoRaWAN server options had to be enabled in the gateway interface and the configurations for the
LoRaWAN settings filled, which were the server address, server port and gateway ID, obtained after
registering the gateway. The gateway was then ready at TTN and the sketch was uploaded to it.
For the device, in its console page at TTN, the register device option was selected and it has necessary to
enable the ABP method, the only one supported by the Dragino gateway. As the Arduino LoRa shield
did not come with the device address "DevAddr", network session key "NwkSKey" and app session key
"AppKey", the values, in this case, were generated by the TTN service.
47
The sketch for the Arduino LoRa shield, available at [130], used in the first experiment, had to be changed
to support the right device address, network session key and app session key fields obtained before. After
installing the necessary libraries, the sketch, which sent a test message, was uploaded. In the serial
monitor it was possible to see that the messages were being sent to the gateway and in the gateway web
UI possible to check that the gateway was receiving them. At TTN the communication from the device
could be confirmed in the Data section of the device page.
With the Arduino LoRa/GPS shield it was necessary to register a new device. As the gateway had already
been registered and there was no need to change its configurations, no changes were made. Only the new
values for the "DevAddr", "NwkSKey" and "AppKey" had to be filled at the new sketch used. Several
sketches were used with the LoRa/GPS shield and the implementation for this experiment had several
challenges, explained in the next chapter. A sketch [131] was found that was able to be uploaded to the
Arduino LoRa/GPS shield. This new sketch required the installation of two new libraries, one for the
GPS [132] and another for LMIC (LoraMAC-in-C) [133]. After the sketch for the LoRa/GPS shield was
uploaded, where the latitude, longitude and altitude were sent as the payload, the communication to the
TTN service was confirmed. Figure 4.13 shows the LoRa/GPS shield experiment conducted outdoors to
see if the GPS location could be found.
Figure 4.13: LoRa/GPS shield experiment.
48
Chapter 5
Results and Analysis
In this chapter, the results of the smart home project obtained in the previous chapter are presented. The
chapter starts with a review of the Sigfox boards and the results achieved for the smart home project.
The results of the synchronization with the IoT platforms are presented along with an analysis on their
performance. An analysis of the LoRa kit is conducted with its results discussed.
49
5.1 Sigfox Boards
For Sigfox only one module was considered to use as the prototype. The module could be used with a
shield on an Arduino, Raspberry Pi or Waspmote boards. Table 5.1 presents the three shield options from
Cooking Hacks for the module, with the Sigfox shield, and their associated prices. Two developer kits
were also considered, the Akeru from Snootlab [134] and the SmartEverything board [113], which had
prices around 90 eand 85 erespectively. All prices do not include tax or shipping costs.
Table 5.1: Shield solutions for the Sigfox module.
Arduino Raspberry Pi Waspmote
Shield Price 65 e[135] 90 e[136] 160 e[137]
Board Price 23 e 40 e +160 e
The Arduino was chosen for providing the cheaper solution, and the SmartEverything board for the
connection to the Sigfox network and for having a series of embedded sensors. The first board used, the
TD1208, had already been acquired before the start of this project.
TD1208 Board
The tests conducted with this board where meant to test the Sigfox network. It was also the first board to
be used with an IoT platform, through the creation of a callback, where the device ID and time were sent
as data. The board is no longer available, but Telecom Design offers other Sigfox devices. The results
from the Carriots platform can be seen in figure 5.1. The tests using this board, both with Sigfox and the
Carriots platform, proved successful and the results were good. The board proved a good starting point
for the project and through it, it was possible to see how the Sigfox back-end worked. It also provided a
better insight at how the callback process was made.
Figure 5.1: Example of a Sigfox message received at the Carriots IoT platform.
SmartEverything Board
The tests using this board were made using code from examples, in order to understand how the board
worked and how to program it. All tests using the board were made connected to a power supply and
never using batteries because, although the board uses a Sigfox module, that is very energy efficient, the
board is not. All Sigfox tests were successful. This board, shown in figure 5.2, ended not being used
to its full potential. Additional tests were envisioned for it, such as, using the gyroscope to attach the
module to a door or drawer. In the test envisioned, the user could be alerted that the front door, or a
50
drawer, of their house had been opened. As the token for this board expired and because the steps taken
to synchronize the Arduino board with shield and Sigfox module to the IoT platforms presented difficult
challenges, the planned tests for this board were not achieved. The problem faced where the uploads were
not possible was not identified and even the beta version of the Arduino IDE used was not found after,
leading to believe that the problem had been resolved with a new software update.
Although the full use of the board was not possible, the tests conducted with it allowed to see that this
board had a greater learning curve than the Arduino with the Sigfox shield, and sketches designed for it
would be harder to code, mainly because it had its own Sigfox library, it its own set functions.
Figure 5.2: The SmartEverything board [138].
Sigfox Radio Shield for Arduino
The Arduino with shield and Sigfox module, shown in figure 5.3, was the board used as the prototype for
the smart home project and the one used with seven IoT platforms. The objective with this board was to
be able to send messages to the Sigfox back-end and to redirect them to IoT platforms. It was the board
with the faster learning curve. The sensors tested worked as expected, except for the rain sensor which
with a single drop of water accused a flood warning. The accelerometer was tested several times but it
was not possible to make it work, or conclude if it even worked. Although all sensors described in section
4.2.3 were tested with the Arduino, the SHT31 sensor and the PIR motion sensor were the ones chosen
to be used with the Sigfox module. The SHT31 sensor was preferred to the other temperature sensor,
the DHT11, because it had more accurate readings for both temperature and humidity. The decision to
first use the SHT31 sensor for the prototype was made to ensure that the smart home solution could be
implemented, before starting to add more sensors to the prototype.
The tests to the Sigfox back-end were successful, but the messages could only be viewed in hexadecimal.
As the temperature and humidity values were an eight byte hexadecimal value, the display information
shown in figure 5.4 was created. It was found that the first code used to convert the float values to
hexadecimal, needed to send the information to the Sigfox back-end, was not working correctly, as shown
in figure 5.5. A new way to send the data, by using a union, proved successful.
51
Figure 5.3: Cooking hacks Sigfox radio shield and module [114].
Figure 5.4: Custom payload configuration at the Sigfox back-end.
The Cooking Hacks Sigfox module presented a problem which could not be solved throughout the work
relating to the upload of sketches to the Arduino. Theoretically, once assembled, the Arduino Sigfox shield
with the Sigfox module, should be able to connect to the Arduino IDE software for sketch uploading.
The Shield used to connect the Arduino board to the Sigfox module has a switch that selects the serial
connection (USB or XBEE). After researching the problem thoroughly in forums and help guides, several
attempts were made to solve it, starting with the switch on the shield, to switching the software serial
ports on the sketch. After several failed attempts, and finding that this was a common problem with the
shield, the solution found was to upload the sketches when the Sigfox module was not connected to the
shield.
While this method worked, it is believed to be the cause for the Sigfox module to sometimes report not
being switched on successfully. This sometimes presented errors when the prototype was first turned on,
as seen in figure 5.6. In the figure it can be seen that the module is first switched on correctly but the
packet sent gave an error command; while after, the module does not switch on correctly but says that the
message was sent. Sometimes when the module gave the packet sent error the message still arrived at the
Sigfox back-end. This is believed to be the reason for receiving an event message warning at the Sigfox
back-end, as figure 5.7 shows. This warning is sent when the message counter number is not the same
Figure 5.5: Custom payload display attempt.
52
as the one expected by Sigfox, meaning that some message might have been lost. To solve this problem
the sketch created for the prototype did not use the setup function, only using instead the loop function,
which meant that every time the prototype would send a message it would re-initialize the sensor and
Sigfox module to avoid any errors. The sketch used sent information to the back-end every twenty minutes
to ensure that the daily limit allowed by Sigfox would not be broken. The temperature and humidity
values were 4 bytes each, making the payload 8 bytes total. This was not the most efficient way to send
the temperature and humidity as both can be sent using only 2 bytes each.
Figure 5.6: Sigfox module fails to switch on.
Figure 5.7: A Sigfox warning event for a break in message sequence.
The Narcoleptic sleep code used in the Arduino sketch did not prove very effective. Two tests were
conducted to see how much time the device would last only powered by batteries. In the test with the
9V battery the sketch was made to send data in twenty minute intervals, but after further studying this
type of battery with Arduino solutions it was found that this type of battery drains fast. After a few
hours a change to a two hour interval between messages was made. Based on the last message received at
the Sigfox back-end, the device was powered by the battery for sixteen hours with the twenty minute
interval plus an additional fifteen more hours with the two hour interval, reaching a total of thirty one
hours using the 9V battery. The test with the eight 1.5V batteries used from the beginning a two hour
interval between messages and managed to stay on for four days before losing power.
The second sketch created, which used the PIR sensor to detect movement, had the message received at
the Sigfox back-end successfully, but its implementation was not further developed due to time constraints.
The downlink test made was successful, but because there was not a need for downlink messages in the
smart home system designed, further tests were not performed.
Only one email callback was created for the prototype where the custom fields for the temperature and
humidity, already parsed by the Sigfox back-end were sent in the payload. In figure 5.8 the message
received at the email client is presented.
53
Figure 5.8: Example of an email received using a Sigfox data callback.
This module proved difficult to use, as every time a sketch was uploaded to it the Sigfox module had to
be removed. Still the Sigfox functions for the module were simpler and easier to implement than the
SmartEverything ones, which made possible to perform more tests. Although the Arduino Sigfox shield
had its challenges, all tests originally designed for it were achieved and successful.
Sigfox Platform Results
As the Sigfox back-end was constantly being updated some of the documentation for synchronizing Sigfox
devices with platforms were out of date and could no longer be followed. Other platforms were still in
development and did not have full Sigfox compatibility, such as not supporting custom fields in their
JSON format, which meant that the data sent to Sigfox had to be parsed at the platforms.
The first platform used with the prototype was the CloudThing platform. It was chosen because it was
free when used with five or less devices and it provided the use of email and SMS message alerts. The
callback for this platform followed the same steps as the Thinger platform with a productId value obtained
after registering a device at the platform necessary to put in the URL field at the Sigfox callback. Many
attempts were made to synchronize with this platform but all proved unsuccessful. Figure 5.9 shows the
result of a failed callback to the CloudThing platform at the Sigfox back-end.
Figure 5.9: Callback error to Cloudthing platform.
Wia was another platform tested, chosen for having a visually appealing dashboard for IoT devices, which
was one of the objectives for the smart home system. The first time the platform was tested, it required
certain API fields for the Sigfox callback, which the Sigfox account used did not have access to. So, the
use of this platform was not deemed possible. However, when reviewing the platforms for the project,
54
the Wia platform was found to have radically changed. It did not allow for the creation of a dashboard
anymore but it could be used to send SMS alerts and Twitter messages, and the way the callback was
used was now different. It was then possible to sync it with the Sigfox back-end. To do it, first an
integration with the platform was needed. To achieve it, it was necessary to: enter the Group section at
the Sigfox back-end, where the user is registered; go to the API ACCESS section; create a new API with
DEVICES_MESSAGES[R] option enabled, for the necessary keys to be generated. These keys would
then be used at the platform side to complete the integration process. Then the callback was created in
the same way as the Thinger platform, explained in section 4.2.4, with the only difference being that the
JSON body structure for this platform was slightly different. The platform did not support custom fields
in the JSON body, so the data had to be parsed at the Wia platform with JavaScript code. Figure 5.10
shows an event on the Wia platform where the payload sent from the Sigfox back-end can be seen in the
sigfoxData field. Besides offering its own cloud solution, Wia also offers the possibility to be self-hosted
on the customers own cloud solution. Although the platform was used, it was not possible to achieve the
parsing of the data or the use of the SMS and twitter solutions.
Figure 5.10: Data received at the Wia platform.
The Tago platform was another that, like Wia, did not offer the possibility to receive custom Sigfox fields.
However, it was possible to create a custom dashboard for IoT devices. The callback for this platform
had a JSON body structure which differed from all other platforms. The hexadecimal data from Sigfox
was not possible to be parsed on this platform as well. Widgets were created for all fields sent, such as
the device ID, SNR, RSSI, base station ID and hexadecimal data. Figure 5.11 shows a view of the data
widget created.
The Microsoft Azure platform was also tested. This was the most complex, difficult and time consuming
platform to set up. Like Amazon AWS it had a dedicated simplified bridge at the Sigfox back-end, called
Microsoft Azure IoT Hub. Microsoft offers the possibility to build an IoT dashboard but to build it
requires the use of a business analytics service, the Power BI. The use of this platform was abandoned for
55
Figure 5.11: Tago dashboard view of the data widget.
two main reasons: first because setting the callback to this platform had already been very time consuming;
and second, because the synchronization with the Power BI service had very little documentation to help
construct the IoT dashboard. Based on the already difficult set up of the Sigfox callback the use of the
second service to display the information was deemed to complex to achieve. For Microsoft, although
through the Sigfox back-end it was possible to confirm that the callback created was working, it was not
possible to view this information in the Microsoft cloud. Only some statistics, like how many messages
were received, could be accessed.
Amazon AWS, although equally difficult to implement, possessed a friendlier user interface and better
documentation for Sigfox integration. Figure 5.12 shows a partial view of the DynamoDB table, explained
in section 4.2.4, and figure 5.13a shows a detailed view of a message in that table. Figure 5.13b presents
the Amazon AWS app where it was possible to confirm that the Sigfox device was active, the storage it
already used (709833 bytes), and the number of messages received (4184).
The Microsoft and Amazon IoT cloud services proved the most challenging. It was possible to synchronize
the prototype with both of them, even though the creation of IoT dashboards was not achieved. Amazon
did not have support for custom field data at the JSON structure, unlike Microsoft, but both had the
possibility to parse the Sigfox data on their services. These were the only platforms which differed from
the usual IoT platform business model, which offers "pack" solutions depending on the number of devices
used. Instead they offer one year free connectivity to their respective platforms, after which the user
would be charged according to the use of the platform. These charges would be related to the number of
messages sent, the time on air, the size of the messages, among others. These platforms were concluded to
be directed to enterprise solutions, like IoT fleet management services, and have the greatest learning
curve compared to all the rest tested.
Figure 5.12: Amazon AWS DynamoDB table.
Another platform used was Databoom. The callback setup was the same as the Thinger platform. Although
not yet compatible with custom Sigfox fields, after exchanging some emails with the customer support
they were able to create two custom signals, for this particular case, one for the temperature and another
56
(a) A detailed view of one message from the DynamoDB
table.
(b) The AWS smartphone application.
Figure 5.13: Results obtained with Amazon AWS platform
for the humidity, shown in figure 5.14. With these new signals, it was possible to create a complete IoT
dashboard with all data fields sent from the prototype. The widget created for the temperature and
humidity is shown in figure 5.15. This platform was one were a complete IoT dashboard for the smart
home system planned was achieved.
The most successful IoT platform tested was the Thinger platform. Through the documentation from
this platform, not only was it possible to have a functioning and complete IoT dashboard, but also gain
a better understanding of how the process of synchronization between the Sigfox back-end and the IoT
platforms worked. It was through the use of this platform that most problems faced with the others
were resolved. In figure 5.16 the Thinger dashboard is shown, with widgets for the temperature and
humidity, the SNR, the RSSI, the device ID, and a map showing the location of the base station, based
on the latitude and longitude values. Widgets for the latitude, longitude, time and base station ID were
also created. The widgets are the result of the data bucket created at the platform. This was the most
successful dashboard implementation, completing the smart home architecture designed for the project,
marking the success of the Sigfox solution implementation.
57
Figure 5.14: Custom signals received at the Databoom platform.
Figure 5.15: Custom IoT dashboard built at the Databoom Platform.
Through the use of all seven platforms a better understanding of the Sigfox architecture was achieved.
The Sigfox back-end was considered difficult to navigate and the options for device management hard to
find. Still, the Sigfox architecture solution for the smart home, initially proposed, was achieved. However,
from the seven platforms used, the solution was only possible on two of them, the Thinger and Databoom.
Although on the other platforms a dashboard was not able to be created, the synchronization with them
was still achieved, except for the CloudThing platform.
58
Figure 5.16: Thinger platform custom dashboard.
5.2 LoRa Dragino Kit
For the LoRa solution, two modules were considered, both for LoRa and LoRaWAN. The modules, from
Cooking Hacks, were to be used with a shield on a Arduino, Raspberry Pi or Waspmote board. Table 5.2
shows the six Cooking Hacks shield options and their prices. This solution would also need a gateway. As
LoRa gateways are very expensive, the two options considered were: to build one, using a Raspberry Pi;
or to find an already built gateway solution which would not be very expensive. The custom Raspberry Pi
gateway had a price around 150 e[87], and the cheap gateway solution found was the Dragino kit which
had a price around 90 e. All prices do not include tax or shipping costs.
Table 5.2: Shield solutions for the LoRa module.
Arduino Raspberry Pi Waspmote
LoRa Shield Price 75 e[139] 85 e[140] 147 e[141]
LoRaWAN Shield Price 90 e[142] 95 e[143] 163 e[144]
Board Price 23 e 40 e +160 e
The model chosen for the LoRa solution ended up being the Dragino kit. This decision was made based
on the study of LoRa gateway implementation, which after the time spent with Sigfox, was deemed
to complex and difficult to implement in the time available for this work. As the Dragino kit already
possessed a LoRa gateway, two LoRa nodes, and several sensors, it was found to be a better alternative
for the LoRa tests.
59
Dragino Gateway
The Dragino LG01 gateway proved a good device to gain knowledge on LoRa technology. It was not
designed to support LoRaWAN and, as such, only supports one LoRaWAN channel, instead of eight. The
gateway can only receive one packet at a time, usually taking two to three seconds to process each packet,
which equates to roughly twenty to thirty packets per minute. Using LoRaWAN it can communicate with
other LoRa devices, as long as they share the same frequency, spread factor, bandwidth, preamble length
and sync word (a one byte value used to differentiate LoRa networks that use the same frequency bands).
As a result, the gateway cannot support many devices, with lab tests showing packet loss when fifty to
sixty devices each send messages within ten minute intervals [145].
RadioHead Protocol Tests
In the RadioHead tests two other ways to connect the gateway to the home network were tried. The first
by connecting the gateway directly to the home Wi-Fi router, through its WAN port. The gateway would
then act as a Wi-Fi access point for the home network, sharing its Internet connection through its access
point or by connecting to its LAN port. And the second by connecting the gateway to a Wi-Fi range
extender. Both tests proved unsuccessful.
To be able to monitor both the device and the gateway in the first LoRa experience, a new program,
ZTerm [146], was installed. This was due to the Arduino IDE only being able to show the serial monitor
of the device connected to the PC. The experience was successful and the result of the connection can be
seen in figure 5.17.
(a) The LoRa device monitor window. (b) The LoRa gateway monitor window.
Figure 5.17: LoRa device and gateway tests.
Figure 5.18 shows the result of the ThingSpeak platform test. At the platform two widgets were created,
one for the temperature and another for the humidity. The platform had a good user interface. The LoRa
architecture, proposed in section 4.3, was achieved with the RadioHead protocol, using this platform.
60
Figure 5.18: Temperature and humidity values in ThingSpeak platform.
LoRaWAN Protocol Tests
The configuration of the gateway to support LoRaWAN proved very time consuming. A new firmware
[147] add to be installed to support LoRaWAN connectivity. The upload of this firmware proved very
challenging. Several reboots were necessary until the upload was finally successful. The upload of the
LoRaWAN sketch to the gateway was also complicated. To do it it was necessary to upload a new MCU
profile. Two versions of this file were available, version 2 and 3. Although the documentation advised the
installation of the latest version 3 of the file, upon first installing it the upload was unsuccessful. After
other tries with the file were attempted, followed by several resets, the upload was finally successful. Even
though the version 3 was uploaded, the gateway showed version 2 installed. After these steps, and the
gateway configuration, both at the web interface and at TTN, the gateway appeared as "connected" on
the service.
The gateway only supports Activation By Personalization, and can only receive a packet using one
frequency channel. This meant that the Arduino LoRa shield had to be configured to send the payload
using only one frequency, and the gateway had to be on that same frequency or the data will be lost.
The sketches used sent the payload using three frequencies, the 868.1, the 868.3, and the 868.5 MHz. To
achieve the results necessary two of the frequencies should be disabled. As the gateway was configured for
only the 868.1 MHz frequency, only the messages using that frequency were received. Because the other
two frequencies ended up not being disabled, when the device communicated it gave two pending errors
for the packets sent from those frequencies.
The first experience to send a simple tests message proved successful with the result shown in figure 5.19,
which presents the data payload, sent in hexadecimal.
For the second experience, the new sketch available at [148] failed to upload to the board with the error
"sketch too big" displayed. This was found to be related to the libraries used for the sketch not being
correct, even though they were provided specifically for this test. After trying to find a solution, a new
example available at [131] was found. This new sketch required the installation of two new libraries, one
for the GPS [132] and another for LMIC (LoraMAC-in-C) [133]. After uploading the sketch, the messages
61
Figure 5.19: The successful reception of the payload at the TTN platform.
were shown to not being received at the platform. Using the serial monitor it was confirmed that the new
LMIC library was defined for the 434 MHz channel frequency. The frequency had to be changed in the
"lorabase.h" file, found inside the source library folder. After the change in frequency the messages were
received at the platform.
At TTN, it was also possible to expand the view of each payload to see some statistics about the message.
One of these parameters available was the message time-on-air. The GPS LoRaWAN message contained
32 bytes, which equated to an average time on air around 75 milliseconds. Following this test, and keeping
the TTN fair access policy in mind, of allowing only thirty seconds uplink time, per device, per day [149],
means that four hundred LoRa messages could be sent in a day doubling what Sigfox offers.
TTN has a security feature against replay attacks for ABP devices, which uses frame counters for the
device every time a message is sent. If either the device or the network receives a message with a frame
counter that is lower than the expected one, the message is ignored. For this type of device the frame
counter resets every time the device restarts, preventing the messages from being received at the platform.
Because of this every time an ABP device receives a new power cycle it is necessary to then reset the
frame counters at the platform. The possibility to disable these frames is also possible, but doing so will
expose the device to possible replay attacks.
The GPS test was made both indoors and outdoors and a signal was not found. Several attempts were
made to solve the problem, by switching the software serial ports, but although the device sent information
to the network service, the payload remained empty. This led to the possible conclusions that: there was
a mistake in the code; the GPS module was not properly connected to the Arduino board; the library for
the GPS was not the right one; or the GPS module was not functioning properly. Figure 5.20 shows the
result of the failed GPS test.
Figure 5.20: The unsuccessful reception of the GPS signal at TTN.
62
With LoRaWAN the proposed architecture was not achieved as TTN is a network server that does not
provide capabilities for creating a dashboard. The challenges faced with the LoRaWAN tests proved
very time consuming and understating how the devices and the gateway worked was more difficult than
originally though.
63
64
Chapter 6
Conclusions
In this chapter, a summary of the work and the conclusions are presented. The objectives are revisited
and possible continuations of this work are touched upon.
65
6.1 Developed Work
This thesis focuses on the use of IoT solutions for the smart home, with a particular focus on two LPWAN
technologies, Sigfox and LoRa. A detailed study is done on both technologies and a prototype solution for
a smart home project is developed.
In Chapter 2, several topics relating to IoT, such as its meaning, definitions and architecture are discussed.
Some of the most important technologies which enable the IoT are addressed, such as M2M communications
and cloud computing, while others that might be implemented in the future, like fog computing, are
touched upon. Also addressed are some of the challenges the IoT currently faces, such as security, privacy,
standards and rights. Each of these topics is studied in light of the challenges that IoT faces today.
In Chapter 3, several technologies which enable the IoT are reviewed and their most important features
explained, ending with a focus on LPWAN technologies. A more in depth discussion is given for the two
technologies used in the thesis, Sigfox and LoRa. Their characteristics, architecture and security are
reviewed. A discussion on their main differences is presented, followed by an analysis on the state of the
art. In the latter a look at the current hardware offers of both Sigfox and LoRa is given, and examples of
current IoT applications are presented.
In Chapter 4, the smart home project is developed, using Sigfox and LoRa technologies. Two architectures
for Sigfox and LoRa are proposed and the steps to achieved them explained. With Sigfox, three developer
kits are tested, with their experiences detailed, and a temperature and humidity prototype is used to
simulate a smart home IoT device. The prototype is then synced with several IoT platforms to be viewed
by a customer for a better user friendly experience. The experiences with the LoRa gateway and devices
are detailed, and their synchronization with a network server and a platform is explained.
In Chapter 5, an analysis of the challenges faced during the various tests is presented along with the
results of the IoT platforms solutions. An analysis is done on the experiences with Sigfox and LoRa.
Most of the objectives defined in the thesis are achieved, starting with the study of IoT, its challenges and
technologies, specifically Sigfox and LoRa. The prototype for Sigfox is created successfully and the results
obtained at the Sigfox back-end are the ones which were initially desired. Seven IoT platforms are used:
one, which failed to be implemented; four, that do not achieve the desired result; and two more, which
achieve the objectives first established. The technologies are compared and their results analyzed. The
four platforms using Sigfox that do not achieve the smart home solution desired are synchronized with the
Sigfox prototype successfully. One of the successful results, the Thinger platform, proved to be the most
suitable choice for a smart home project.
With LoRa, a prototype as not achieved because the technology proved to complex and time consuming to
implement mainly because of the study necessary to understand and use its gateway and devices. Although
the gateway proved effective in the work done, the fact that it did not support the full LoRaWAN protocol
66
was found to be lacking. The tests conducted were made to better understand the technology and how to
implement it. Only one dashboard is used with this technology and successfully implemented. A network
server is also used with two tests conducted, one which worked and the other did not.
Based on the experiences of this work it is concluded that both Sigfox and LoRa technologies can be used
in smart home devices and both can have a future in the market. However, through the study and use
of both, it was also possible to conclude that neither can be used as the sole technology in the smart
home, mainly due to their limitations and low level interaction, meaning most devices will adopt a passive
stance, which goes against the normal use of devices in a home, where users like to interact with their
surroundings. After implementing Sigfox and LoRa on a smart home prototype system, the best solution
for the smart home was found to be Sigfox. Sigfox offers much more support for their customers, while
LoRa is a much more independent technology. This relates, for example, to the fact that Sigfox base
stations are deployed and managed by the company, meaning that users only need to focus on the devices
and the platforms for those same devices. It also offers support through the Sigfox back-end. On the other
hand, for LoRa, it is necessary to deploy and build a gateway or pay to use one from a telecommunications
operator which has deployed it. But solutions like this could not be found today. LoRa also has the
disadvantage of not offering a network service, meaning that one has to be used by third-party companies.
During the study and tests conducted with both technologies, the objectives defined at the start of the
work were found to be too many to achieve, specially relating to LoRa. As neither technology had been
used before, the study and implementation of the prototypes took longer than expected.
It is wished that this thesis will hopefully be of value and could serve as guidance for future smart home
projects. It showcases the possible problems an IoT project can face and provides a deeper understating
on the technologies which power the IoT.
6.2 Future Work
Throughout the course of the work several ideas were thought of for future continuation of the smart
home project.
With Sigfox a possible prototype which made use of downlink messages could be made. Another possibility
would be to synchronize various devices with IoT platforms. Using those same platforms services like
Twitter, Slack and others could be implemented. A smartphone application could also be developed.
With LoRa technology, a gateway capable of supporting the eight LoRaWAN channels could be used to
test several devices to better compare it with Sigfox. The newly released 1.1 LoRaWAN specification
capable of supporting Class B devices could also be tested. Other experiences like using IoT platforms to
manage more than one device, while also using services like Twitter, Slack or smartphone applications
could be made.
67
Annex A
1 #include <Wire . h>
2 #include <ardu inoS ig fox . h>
3 #include <ardu inoUt i l s . h>
4 #include <arduinoUART . h>
5 #include "cactus_io_SHT31 . h"
6 #include <Narco l ep t i c . h>
7
8 uint8_t socke t = SOCKET0; //Asign to UART0
9 uint8_t e r r o r ;
10 const int er ror_led = 13 ;
11 cactus_io_SHT31 sht31 ;
12 f loat t ;
13 f loat h ;
14
15 uint8_t data [ 8 ] ;
16 union {
17 uint8_t value [ 4 ] ;
18 f loat f v a l ;
19 } u ; // union to conver t f l o a t to by te s t r i n g
20
21 void setup ( ) {}
22 void loop ( ) {
23 S e r i a l . begin (9600) ;
24 pinMode ( error_led , OUTPUT) ;
25 i f ( ! sht31 . begin ( ) ) {
26 S e r i a l . p r i n t l n ( "Could not f i nd the s enso r . Check wi r ing and I2C address " ) ;
27 while (1 ) de lay (1 ) ; }
28
29 ////////////////////////////////
30 // 1 . swi t ch on
31 e r r o r = S ig f ox .ON( socke t ) ;
32 i f ( e r r o r == 0 ) {
33 d i g i t a lWr i t e ( error_led , LOW) ;
34 S e r i a l . p r i n t l n ( "Switch ON" ) ; }
35 else {
36 d i g i t a lWr i t e ( error_led , HIGH) ;
37 S e r i a l . p r i n t l n ( "Switch ERROR" ) ; }
38 ////////////////////////////////
39
40 S e r i a l . p r i n t l n ( " Sensor SHT31 − Humidity/Temperature Sensor " ) ;
41 t = sht31 . getTemperature_C ( ) ;
42 S e r i a l . p r i n t ( "TEMP= " ) ; S e r i a l . p r i n t ( t ) ; S e r i a l . p r i n t l n ( " ∗C" ) ;
68
43 h = sht31 . getHumidity ( ) ;
44 S e r i a l . p r i n t ( "HUMD= " ) ; S e r i a l . p r i n t (h) ; S e r i a l . p r i n t l n ( " %\t " ) ;
45
46 // F i l l s t r u c t u r e f i e l d s
47 u . f v a l = t ;
48 // f i l l ’ data ’ b u f f e r with data
49 data [ 0 ] = u . va lue [ 3 ] ;
50 data [ 1 ] = u . va lue [ 2 ] ;
51 data [ 2 ] = u . va lue [ 1 ] ;
52 data [ 3 ] = u . va lue [ 0 ] ;
53
54 // F i l l s t r u c t u r e f i e l d s
55 u . f v a l = h ;
56 // f i l l ’ data ’ b u f f e r with data
57 data [ 4 ] = u . va lue [ 3 ] ;
58 data [ 5 ] = u . va lue [ 2 ] ;
59 data [ 6 ] = u . va lue [ 1 ] ;
60 data [ 7 ] = u . va lue [ 0 ] ;
61
62 ////////////////////////////////
63 // 3 . send s i g f o x data
64 e r r o r = S ig f ox . send ( data , 8) ;
65 i f ( e r r o r == 0 ) {
66 d i g i t a lWr i t e ( error_led , LOW) ;
67 S e r i a l . p r i n t l n ( "Packet sent OK" ) ; }
68 else {
69 d i g i t a lWr i t e ( error_led , HIGH) ;
70 S e r i a l . p r i n t l n ( "Packet sent ERROR" ) ; }
71 ////////////////////////////////
72 d i g i t a lWr i t e ( error_led , LOW) ;
73 Narco l ep t i c . de lay (1200000) ; // 20 min de lay
74
75 // Never do de l ay s shor t e r than 11 min or
76 // i t w i l l break s i g f o x message l im i t /day
77
78 // Narco l ep t i c . de lay (900000) ; 15 min de lay
79 // Narco l ep t i c . de lay (3600000) ; 1 hour de lay
80 // Narco l ep t i c . de lay (7200000) ; 2 hour de lay
81 }
69
Bibliography
[1] L. Srivastava, “The Internet of Things”, ITU, 2005, pp. 3-4.
[2] M. Weiser, The Computer for the 21st Century, [Accessed Apr. 7, 2018], 1991. [Online]. Available:
https://www.ics.uci.edu/~corps/phaseii/Weiser-Computer21stCentury-SciAm.pdf.
[3] K. Ashton, That ’Internet of Things’ Thing, [Accessed Apr. 7, 2018], 2009. [Online]. Available:
http://www.rfidjournal.com/articles/view?4986.
[4] D. AG, “Industry 4.0 challenges and solutions for the digital transformation and use of exponential
technologies”, Deloitte, 2015, pp. 3-4.
[5] ITU-T, “Series Y: Global Information Infrastructure, Internet Protocol Aspects and Next-Generation
Networks”, ITU, 2012, pp. 2-9.
[6] A. Nordrum, Popular Internet of Things forecast of 50 billion devices by 2020 is outdated, [Accessed
Apr. 7, 2018], 2016. [Online]. Available: https://spectrum.ieee.org/tech-talk/telecom/
internet/popular-internet-of-things-forecast-of-50-billion-devices-by-2020-is-
outdated.
[7] B. Wire, Worldwide spending on the Internet of Things forecast to reach nearly $1.4 trillion in
2021, according to new IDC spending guide, [Accessed Apr. 7, 2018], 2017. [Online]. Available:
https://www.businesswire.com/news/home/20170614005185/en/Worldwide- Spending-
Internet-Things-Forecast-Reach-1.4.
[8] C. U. Usama Mehboob Qasim Zaib, “Survey of IoT communication protocols”, xFlow Research Inc,
2016, pp. 12-16.
[9] Verizon, “State of the Market: Internet of Things 2017”, Verizon, 2017, pp. 2-3.
[10] P. M. Timothy Malche, “Internet of Things (IoT) for building Smart Home System”, IEEE, pp. 65,
2017.
[11] T. E. Centre, “Technical Report M2M/IoT enablement in Smart Homes”, Ministry of Communica-
tions, Government of India, 2017, pp. 6-15.
[12] Deloitte, “Switch on to the connected home”, Deloitte, 2016, pp. 4.
[13] Z. D. Williams, IoT platforms company list 2017 update, [Accessed Apr. 7, 2018], 2017. [Online].
Available: https://iot-analytics.com/iot-platforms-company-list-2017-update/.
[14] G. M. Luigi Atzori Antonio Iera, “The Internet of Things: A survey”, Computer Networks, pp.
2787–2793, 2010.
70
[15] A. V. Jyoti Deogirikar, “Security Attacks in IoT: A Survey”, IEEE, pp. 32–36, 2017.
[16] E. Commission, “Opinion 8/2014 on the on Recent Developments on the Internet of Things”,
European Commission, 2014, pp. 6-7.
[17] M. N. Lukas Krupka Lukas Vojtech, “The Issue of LPWAN Technology Coexistence in IoT
Environment”, Mechatronics, pp. 1–7, 2016.
[18] M. Y. K. Keith E. Nolan Wael Guibene, “An evaluation of Low Power Wide Area Network
Technologies For The Internet Of Things”, Wireless Communications and Mobile Computing
Conference, pp. 439–442, 2016.
[19] Flaticon, Free Vector Icons, [Accessed Apr. 7, 2018], 2018. [Online]. Available: https://www.
flaticon.com/.
[20] L. C. Karen Rose Scott Eldridge, “The Internet of Things: An Overview”, The Internet Society,
2015, pp. 1-45.
[21] A. Banafa, Three Major Challenges Facing IoT, [Accessed Apr. 7, 2018], 2017. [Online]. Available:
https://iot.ieee.org/newsletter/march-2017/three-major-challenges-facing-iot.
html.
[22] M. G. Institute, “The Internet of Things: Mapping the value beyond the hype”, McKinsey, 2015,
pp. 2-9.
[23] W. Wong, What’s the Difference Between Consumer and Industrial IoT?, [Accessed Apr. 7, 2018],
2016. [Online]. Available: http://www.electronicdesign.com/iot/what- s- difference-
between-consumer-and-industrial-iot.
[24] J. M.S.V.D.C. P. Shivangi Vashi Jyotsnamayee Ram, “Internet of Things (IoT) a vision, architectural
elements, and security issues”,
[25] A. N.T. K. Mohsen Hallaj Asghar Nasibeh Mohammadzadeh, “Principal Ingredients and Framework
of Internet of Things (IoT)”, Wireless and Optical Communications Networks (WOCN), pp. 1–5,
2015.
[26] C. E. Michael Weyrich, “Reference Architectures for the Internet of Things”, IEEE Software, pp.
112–116, 2016.
[27] ITU-T, “M2M service layer: Requirements and architectural framework”, Tech. Rep.
[28] H. H. Ved P. Kafle Yusuke Fukushima, “Internet of Things Standardization in ITU and Prospective
Networking Technologies”, IEEE Communications Magazine, pp. 43–49, 2016.
[29] S. Z. Shancang Li Li Da Xu, “The Internet of Things: A Survey”, Springer Science+Business Media,
pp. 243–250, 2014.
[30] V. P.A. P. Alessio Botta Walter de Donato, “Integration of Cloud computing and Internet of
Things: A survey”, Future Generation Computer Systems, pp. 686–689, 2015.
[31] P. C. Charith Perera Prem Prakash Jayaraman, “MOSDEN: An Internet of Things Middleware for
Resource Constrained Mobile Devices”, System Sciences (HICSS), pp. 1–2, 2014.
71
[32] I. ANALYTICS, The IoT Platform Company List 2017, [Accessed Apr. 7, 2018], 2017. [Online].
Available: https://iot-analytics.com/product/list-of-450-iot-platform-companies/.
[33] Microsoft, Azure IoT Suite, [Accessed Apr. 7, 2018], 2018. [Online]. Available: https://www.
microsoft.com/en-us/internet-of-things/azure-iot-suite.
[34] Amazon, AWS IoT Core Overview, [Accessed Apr. 7, 2018], 2018. [Online]. Available: https:
//aws.amazon.com/iot-platform/.
[35] Google, Google Cloud IoT, [Accessed Apr. 7, 2018], 2018. [Online]. Available: https://cloud.
google.com/solutions/iot/.
[36] X. C. Rong N. Chang Wei Cheng, “IEEE Internet of Things Journal Special Issue on Fog Computing
in IoT”, IEEE Sensors Council, pp. 1–2, 2017.
[37] J. Z.S. A. Flavio Bonomi Rodolfo Milito, “Fog Computing and Its Role in the Internet of Things”,
ACM, pp. 13–14, 2012.
[38] Cisco, “Fog Computing and the Internet of Things: Extend the Cloud to Where the Things Are”,
Cisco, pp. 1–5, 2015.
[39] ETSI, Internet of Things, [Accessed May 13, 2018], 2018. [Online]. Available: http://www.etsi.
org/technologies-clusters/technologies/internet-of-things.
[40] IEEE, Internet of Things, [Accessed May 13, 2018], 2018. [Online]. Available: http://standards.
ieee.org/innovate/iot/stds.html.
[41] I. O. for Standardization, ISO/IEC JTC 1/SC 41, [Accessed May 13, 2018], 2018. [Online]. Available:
https://www.iso.org/committee/6483279.html.
[42] ITU, ITU-T: Global Standards for the Internet of Things, [Accessed May 13, 2018], 2018. [Online].
Available: https://www.itu.int/en/ITU-T/techwatch/Pages/internetofthings.aspx.
[43] E. Comission, “Position Paper on Standardization for IoT technologies”, European Research Cluster
on the Internet of Things, 2015, pp. 5-16.
[44] H. K.-V. Pekka Kess, “Standardization with IoT (Internet of Things)”, Management, Knowledge
and Learning Joint International Conference 2016, 2016, pp. 1072-1075.
[45] 3rd Generation Partnership Project, Standardization of NB-IOT completed, [Accessed Apr. 7,
2018], 2018. [Online]. Available: http://www.3gpp.org/news- events/3gpp- news/1785-
nb_iot_complete.
[46] G. T. Santhosh Krishna B V, “A Systematic Study of Security Issues in Internet-of-Things (IoT)”,
I-SMAC (IoT in Social, Mobile, Analytics and Cloud), pp. 107–110, 2017.
[47] F. S. Report, “Internet of Things: Privacy & Security in a Connected World”, FTC, 2015, pp. 7-18.
[48] R. Kemp, “Legal Aspects of the Internet of Things”, Kemp IT Law, 2017, pp. 2-9.
[49] A. W. Mian Muhammad Ahemd Munam Ali Shah, “IoT Security: A Layered Approach for Attacks
& Defenses”, Communication Technologies (ComTech), pp. 104–109, 2017.
72
[50] J. Vincent, Inaudible ultrasound commands can be used to secretly control Siri, Alexa, and Google
Now, [Accessed Apr. 7, 2018], 2017. [Online]. Available: https://www.theverge.com/2017/9/7/
16265906/ultrasound-hack-siri-alexa-google.
[51] T. Warren, Amazon’s Echo Spot is a sneaky way to get a camera into your bedroom, [Accessed Apr.
7, 2018], 2017. [Online]. Available: https://www.theverge.com/2017/9/28/16378472/amazons-
echo-spot-camera-in-your-bedroom.
[52] L. H. Newman, The $10 Hardware Hack That Wrecks IOT Security, [Accessed Apr. 7, 2018], 2017.
[Online]. Available: https://www.wired.com/story/sd-card-hack-iot-zero-days/?utm_
campaign=IFA_WeekendReading_Aug2\&utm_medium=email\&utm_source=newsletter.
[53] L. Hautala, Hackers could use baby monitors to watch your kids too, security experts warn, [Accessed
Apr. 7, 2018], 2015. [Online]. Available: https://www.cnet.com/news/several-baby-monitors-
easily-hacked-security-researcher-finds/.
[54] D. Storm, Researchers hack a pacemaker, kill a man(nequin), [Accessed Apr. 7, 2018], 2015.
[Online]. Available: https://www.computerworld.com/article/2981527/cybercrime-hacking/
researchers-hack-a-pacemaker-kill-a-man-nequin.html.
[55] FTC, FTC Report on Internet of Things, [Accessed Apr. 7, 2018], 2015. [Online]. Available:
https://www.ftc.gov/news- events/press- releases/2015/01/ftc- report- internet-
things-urges-companies-adopt-best-practices.
[56] K. Smith, IoT Security: Risks and Realities, [Accessed Apr. 7, 2018], 2016. [Online]. Available:
https://www.allaboutcircuits.com/news/iot-security-risks-and-realities/.
[57] L. Frenzel, “12 Wireless Options for IoT/M2M: Diversity or Dilemma?”, Electronic Design, 2016,
pp. 16-17.
[58] L. Labs, “Low Power, Wide Area Networks For ’Internet of Things’ Engineers and Decision Makers”,
Link Labs, 2016, pp. 2-15.
[59] S. Tabbane, “IoT Network Planning”, ITU, 2016, pp. 18-107.
[60] M. Hassel, IoT and M2M, What’s the difference?, [Accessed Apr. 7, 2018], 2017. [Online]. Available:
http://www.incognito.com/blog/iot-and-m2m-whats-the-difference/.
[61] T. T.O.K. T. Mario Collotta Giovanni Pau, “Bluetooth 5: a concrete step forward towards the
IoT”, Networking and Internet Architecture, pp. 1–9, 2017.
[62] T. Tirronen, Cellular IoT alphabet soup, [Accessed Apr. 7, 2018], 2016. [Online]. Available: https:
//www.ericsson.com/research-blog/cellular-iot-alphabet-soup/.
[63] O. S.N. S. Jean-Paul Bardyn Thierry Melly, “IoT : The Era of LPWAN is starting now”, European
Solid-State Circuits Conference, 2016, pp. 25-30.
[64] J. Afzal, NB-IoT - The choice of Frequency, Deployment Mode and Coverage, [Accessed May 14,
2018], 2017. [Online]. Available: https://www.netmanias.com/en/post/blog/11745/iot-nb-
iot/nb-iot-the-choice-of-frequency-deployment-mode-and-coverage.
73
[65] P. T.-P. Ferran Adelantado Xavier Vilajosana, “Understanding the Limits of LoRaWAN”, IEEE
Communications Magazine, pp. 1–3, 2017.
[66] 3GPP, First 5G NR Specs Approved, [Accessed Apr. 7, 2018], 2017. [Online]. Available: http:
//www.3gpp.org/news-events/3gpp-news/1929-nsa_nr_5g.
[67] M. Research, “LPWA Technologies Unlock New IoT Market Potential”, LoRa Alliance, 2015, pp.
2-13.
[68] R. Quinnell, Low Power Wide Area Networking alternatives for the IoT, [Accessed Apr. 7, 2018],
2015. [Online]. Available: https://www.edn.com/design/systems-design/4440343/Low-power-
wide-area-networking-alternatives-for-the-IoT.
[69] W. SIG, “LPWAN Technology Decisions: 17 critical features”, Weightless SIG, 2016, pp. 2-5.
[70] Sigfox, Sigfox, [Accessed Apr. 7, 2018], 2018. [Online]. Available: https://www.sigfox.com/en.
[71] ITU-T, Sigfox Joins ITU To Influence International Standardization For The Internet Of Things,
[Accessed Apr. 7, 2018], 2017. [Online]. Available: http://newslog.itu.int/archives/1546.
[72] Sigfox, “Sigfox Technical Overview”, Sigfox, 2017, pp. 4-25.
[73] ——, Messages per day/hour, [Accessed Apr. 7, 2018], 2017. [Online]. Available: https://ask.
sigfox.com/questions/2968/messages-per-dayhour.html.
[74] ——, Sigfox Cloud Interfaces, [Accessed Apr. 7, 2018], 2016. [Online]. Available: https://www.
youtube.com/watch?v=7gTwFbiiJwE.
[75] ——, Callbacks Documentation, [Accessed Apr. 7, 2018], 2018. [Online]. Available: https://
resources.sigfox.com/document/callbacks-documentation.
[76] D. Reuse, Cycleo unveils its first innovative semiconductor IP bringing unprecedented range to
wireless data transmission, [Accessed Apr. 7, 2018], 2009. [Online]. Available: https://www.design-
reuse.com/news/21552/wireless-semiconductor-ip.html.
[77] Semtech, Semtech Acquires Wireless Long Range IP Provider Cycleo, [Accessed Apr. 7, 2018], 2012.
[Online]. Available: http://investors.semtech.com/releasedetail.cfm?ReleaseID=655335.
[78] ——, Network Coverage Based on Semtech’s LoRa Technology to be Available in 15 Major U.S.
Cities, [Accessed May 9, 2018], 2017. [Online]. Available: https://investors.semtech.com/news-
releases/news-release-details/network-coverage-based-semtechs-lora-technology-
be-available-15.
[79] J. J.P.C. R. Jonathan de Carvalho Silva, “LoRaWAN - A Low Power WAN Protocol for Internet of
Things: a Review and Opportunities”, Computer and Energy Science (SpliTech), pp. 1–6, 2017.
[80] A. Z.M. Z. Marco Centenaro Lorenzo Vangelista, “Long-Range Communications in Unlicensed
Bands: the Rising Stars in the IoT and Smart City Scenarios”, IEEE Wireless Communications,
pp. 2–7, 2016.
[81] U. R. Martin Bor John Vidler, “LoRa for the Internet of Things”, International Conference on
Embedded Wireless Systems and Networks, pp. 361–362, 2016.
74
[82] A. Orange, “LoRa Device Developer Guide”, Orange, 2016, pp. 5-11.
[83] V. P. Alexandru Lavric, “LoRa Wide-Area Networks from an Internet of Things Perspective”,
Electronics, Computers and Artificial Intelligence (ECAI), pp. 1–3, 2017.
[84] R. Miller, “LoRa Security Building a Secure LoRa Solution”, MWR Labs, 2016, pp. 5-8.
[85] G. Schatz, Sigfox vs. LoRa: A Comparison Between Technologies & Business Models, [Accessed
Apr. 7, 2018], 2016. [Online]. Available: https://www.link-labs.com/blog/sigfox-vs-lora.
[86] Loriot, LoRa gateways and concentrators, [Accessed Apr. 7, 2018], 2016. [Online]. Available: https:
//www.loriot.io/lora-gateways.html.
[87] Mbed, Building your own private LoRa network, [Accessed May 13, 2018], 2018. [Online]. Available:
https://docs.mbed.com/docs/lora-with-mbed/en/latest/intro-to-lora/.
[88] B. Harpley, LPWAN Low-Power WANs for IoT – Part 2, [Accessed Apr. 7, 2018], 2017. [Online].
Available: https://www.astius.co.uk/2015/12/lpwan-for-iot-part-2/.
[89] I. Morris, Sigfox to Go Public in 2018 – Report, [Accessed Apr. 7, 2018], 2016. [Online]. Available:
http://www.lightreading.com/iot/iot-strategies/sigfox-to-go-public-in-2018---
report/d/d-id/728760.
[90] B. Harpley, Low-Power WANs ( LPWAN ) for IoT – Part 1, [Accessed Apr. 7, 2018], 2017. [Online].
Available: https://www.astius.co.uk/2015/10/iot-lpwan-part1/.
[91] Sigfox, Why certification?, [Accessed Apr. 7, 2018], 2018. [Online]. Available: https://resources.
sigfox.com/document/why-certification.
[92] ——, Sigfox Partner Network, [Accessed Apr. 7, 2018], 2018. [Online]. Available: https://partners.
sigfox.com/.
[93] LoRa, LoRa Transceivers, [Accessed Apr. 7, 2018], 2018. [Online]. Available: https://www.semtech.
com/products/wireless-rf/lora-transceivers.
[94] J. P. Tomas, SK Telecom completed nationwide deployment of LoRa network, [Accessed Apr. 7, 2018],
2016. [Online]. Available: https://www.rcrwireless.com/20160704/carriers/operators-
korea-netherlands-deploy-lora-networks-iot-tag23.
[95] G. Burton, London gets a dedicated IoT network, [Accessed Apr. 7, 2018], 2016. [Online]. Available:
https://www.theinquirer.net/inquirer/news/2471687/london- gets- dedicated- iot-
network.
[96] gemalto, Narrowband IoT (NB-IoT), [Accessed Apr. 7, 2018], 2018. [Online]. Available: https:
//www.gemalto.com/m2m/development/innovation-technology/nb-iot.
[97] J.-P. Joosting, Narrowband IoT functionality demonstarted in the field, [Accessed Apr. 7, 2018],
2017. [Online]. Available: http://www.mwee.com/news/narrowband- iot- functionality-
demonstarted-field?news_id=91793.
[98] S. Shah, Cisco launches global NB-IoT platform, [Accessed Apr. 7, 2018], 2018. [Online]. Available:
https://internetofbusiness.com/cisco-nb-iot-platform-worldwide/.
75
[99] Amazon, Amazon Go, [Accessed Apr. 7, 2018], 2018. [Online]. Available: https://www.amazon.
com/b?node=16008589011.
[100] B. Buy, Google Home, [Accessed Apr. 7, 2018], 2018. [Online]. Available: https://www.bestbuy.
com/site/google-home-white-slate-fabric/5578849.p?skuId=5578849.
[101] A. Villas-Boas, 14 ways you can control your home with your voice using Amazon’s Echo and Alexa,
[Accessed Apr. 7, 2018], 2017. [Online]. Available: http://www.businessinsider.com/amazon-
echo-alexa-control-smart-home-with-voice-2017-1/#smart-home-hubs-compatible-
with-alexa-1.
[102] Amazon, Amazon Key, [Accessed Apr. 7, 2018], 2018. [Online]. Available: https://www.amazon.
com/b?ie=UTF8\&node=17285120011.
[103] D. Bird, Door Bird, [Accessed Apr. 7, 2018], 2018. [Online]. Available: https://www.doorbird.
com/.
[104] elgato eve, Eve Degree, [Accessed Apr. 7, 2018], 2018. [Online]. Available: https://www.elgato.
com/en/eve/eve-degree.
[105] Kasita, Kasita, [Accessed Apr. 7, 2018], 2018. [Online]. Available: https://kasita.com/.
[106] Sigfox, Sens’it, [Accessed Apr. 7, 2018], 2018. [Online]. Available: https://www.sensit.io/.
[107] T. B. Corporation, Bt.tn, [Accessed Apr. 7, 2018], 2017. [Online]. Available: https://bt.tn/
sigfox/.
[108] Sigfox, Sigfox and Louis Vuitton partner for innovative luggage tracker, [Accessed Apr. 7, 2018],
2018. [Online]. Available: https://www.sigfox.com/en/news/sigfox-and-louis-vuitton-
partner-innovative-luggage-tracker.
[109] E. Home, Smart Home Monitoring System, [Accessed Apr. 7, 2018], 2017. [Online]. Available:
https://eddyhome.com/how-eddy-helps/eddy-in-your-home/.
[110] IBM, Implement your first IoT and blockchain project, [Accessed Apr. 7, 2018], 2018. [Online].
Available: https://www.ibm.com/internet-of-things/spotlight/blockchain.
[111] G. Eastwood, Why blockchain is the future of IoT, [Accessed Apr. 7, 2018], 2017. [Online]. Available:
https://www.networkworld.com/article/3200029/internet-of-things/why-blockchain-
is-the-future-of-iot.html.
[112] T. Design, “TD1208 Evaluation Board User’s Guide”, Telecom Design, 2014, pp. 6-9.
[113] SmartEverything, SmartEverything, [Accessed Apr. 7, 2018], 2016. [Online]. Available: https:
//www.smarteverything.it/.
[114] C. Hacks, Sigfox Radio Shield for Arduino, [Accessed Apr. 7, 2018], 2018. [Online]. Available:
https://www.cooking-hacks.com/sigfox-radio-shield-for-arduino-868-mhz.
[115] ALTAIR, Internet of Things Platform, [Accessed May 10, 2018], 2011. [Online]. Available: https:
//www.carriots.com/.
76
[116] nicolsc, SmartEverything Hello World, [Accessed Apr. 7, 2018], 2016. [Online]. Available: https:
//github.com/nicolsc/smarteverything-hello-world.
[117] brabl2, Narcoleptic, [Accessed Apr. 7, 2018], 2015. [Online]. Available: https://github.com/
brabl2/narcoleptic.
[118] Cloudthing, Internet of Things made simple, [Accessed Apr. 7, 2018], 2018. [Online]. Available:
https://cloudthing.io/.
[119] Tago, Tago, [Accessed Apr. 7, 2018], 2018. [Online]. Available: https://tago.io/.
[120] Wia, Where People and Things go to talk, [Accessed Apr. 7, 2018], 2018. [Online]. Available:
https://www.wia.io/.
[121] Thinger, Open Source IoT Platform, [Accessed Apr. 7, 2018], 2018. [Online]. Available: https:
//thinger.io/.
[122] Databoom, A brand new IoT WEB app, [Accessed Apr. 7, 2018], 2018. [Online]. Available: https:
//databoom.com/it/.
[123] Amazon, AWS IoT Core, [Accessed Apr. 7, 2018], 2018. [Online]. Available: https://aws.amazon.
com/iot-core/.
[124] Dragino, LoRa IoT development Kit, [Accessed Apr. 7, 2018], 2018. [Online]. Available: http:
//www.dragino.com/products/lora/item/120-lora-iot-kit.html.
[125] ——, “LG01 LoRa Gateway User Manual”, Dragino, 2017, pp. 1-55.
[126] Tindie, LG01 LoRa OpenWrt IoT Gateway, [Accessed Apr. 7, 2018], 2018. [Online]. Available:
https://www.tindie.com/products/edwin/lg01-lora-openwrt-iot-gateway/.
[127] M. McCauley, RadioHead Packet Radio library for embedded microprocessors, [Accessed Apr. 7,
2018], 2014. [Online]. Available: http://www.airspayce.com/mikem/arduino/RadioHead/.
[128] ThingSpeak, IoT Analytics, [Accessed Apr. 7, 2018], 2018. [Online]. Available: https://thingspeak.
com/.
[129] TheThingsNetwork, Building a global Internet of Things Network Together, [Accessed May 15,
2018], 2018. [Online]. Available: https://www.thethingsnetwork.org/.
[130] Dragino, Arduino Profile Examples, [Accessed Apr. 7, 2018], 2017. [Online]. Available: https:
//github.com/dragino/Arduino- Profile- Examples/blob/master/libraries/Dragino/
examples/LoRa/LoRaWAN/Arduino_LMIC/Arduino_LMIC.ino.
[131] ——, LoRa/GPS Shield, [Accessed Apr. 7, 2018], 2017. [Online]. Available: http://wiki.dragino.
com/index.php?title=Lora/GPS_Shield.
[132] mikalhart, TinyGPS, [Accessed Apr. 7, 2018], 2013. [Online]. Available: https://github.com/
mikalhart/TinyGPS.
[133] goodcheney, Arduino LMIC Master, [Accessed Apr. 7, 2018], 2017. [Online]. Available: https:
//github.com/goodcheney/Arduino-Lmic-master.
77
[134] Snootlab, Akeru beta 3.3, [Accessed May 12, 2018], 2016. [Online]. Available: https://snootlab.
com/shields-snootlab/829-.html.
[135] C. Hacks, Sigfox Radio Shield for Arduino - EU, [Accessed May 12, 2018], 2016. [Online]. Available:
https://www.cooking-hacks.com/sigfox-radio-shield-for-arduino-868-mhz.
[136] ——, Sigfox Shield for Raspberry Pi - EU, [Accessed May 12, 2018], 2016. [Online]. Available: https:
//www.cooking-hacks.com/sigfox-shield-for-raspberry-pi-868-mhz-xbee-socket.
[137] ——, Waspmote Sigfox SMA 4.5 dBi - Europe, [Accessed Mat 12, 2018], 2016. [Online]. Available:
https://www.cooking-hacks.com/waspmote-sigfox-sma-4-5-dbi-868.
[138] Sigfox, Arrow Smart Everything, [Accessed Apr. 7, 2018], 2018. [Online]. Available: https://
partners.sigfox.com/products/smart-everything.
[139] C. Hacks, LoRa Radio Shield for Arduino - 868 MHz, [Accessed May 12, 2018], 2016. [Online].
Available: https://www.cooking-hacks.com/lora-radio-shield-for-arduino-868-mhz.
[140] ——, SX1272 LoRa Shield for Raspberry Pi - 868 MHz, [Accessed May 12, 2018], 2016. [Online].
Available: https://www.cooking-hacks.com/sx1272-lora-shield-for-raspberry-pi-868-
mhz.
[141] ——, Waspmote SX1272 LoRa module SMA 4.5 dBi - 868 MHz, [Accessed May 12, 2018], 2016.
[Online]. Available: https://www.cooking-hacks.com/waspmote-sx1272-lora-sma-4-5-dbi-
868-mhz.
[142] ——, LoRaWAN Radio Shield for Arduino - EU, [Accessed May 12, 2018], 2016. [Online]. Available:
https://www.cooking-hacks.com/lorawan-radio-shield-for-arduino-868-mhz.
[143] ——, LoRaWAN Shield for Raspberry Pi - EU, [Accessed May 12, 2018], 2016. [Online]. Available:
https://www.cooking- hacks.com/lorawan- shield- for- raspberry- pi- 868- mhz- xbee-
socket.
[144] ——, Waspmote LoRaWAN SMA 4.5 dBi - Europe, [Accessed May 12, 2018], 2016. [Online].
Available: https://www.cooking-hacks.com/waspmote-lorawan-sma-4-5-dbi-868-mhz.
[145] Dragino, Welcome to Dragino Wiki Page, [Accessed Apr. 7, 2018], 2018. [Online]. Available:
http://wiki.dragino.com/index.php?title=Main_Page.
[146] D. P. Alverson, ZTerm - Macintosh Modem Communications, [Accessed Apr. 7, 2018], 2012. [Online].
Available: http://www.dalverson.com/zterm/.
[147] Dragino, Dragino Download Server, [Accessed Apr. 7, 2018], 2018. [Online]. Available: http:
//www.dragino.com/downloads/index.php?dir=motherboards/ms14/Firmware/IoT/.
[148] goodcheney, Arduino Profile Examples, [Accessed Apr. 7, 2018], 2017. [Online]. Available: https:
//github.com/goodcheney/Arduino-Profile-Examples/blob/patch-4/libraries/Dragino/
examples/LoRa/LoRaWAN/LoRa_GPS_Shield_TTN.
78
[149] Arjan, Limitations: data rate, packet size, 30 seconds uplink and 10 messages downlink per day Fair
Access Policy, [Accessed Apr. 7, 2018], 2017. [Online]. Available: https://www.thethingsnetwork.
org/forum/t/limitations-data-rate-packet-size-30-seconds-uplink-and-10-messages-
downlink-per-day-fair-access-policy/1300.
79
