scieee Science in your language
[en] (orig)

Remote biometrical monitoring system via IoT

Pedro de Castro Albergaria · 2020

Abstract

Os sistemas de Internet of Things (IoT) estão a experienciar um rápido crescimento devido à sua aplicabilidade em vários domínios, desde cidades inteligentes até aos cuidados de saúde. Nestes sistemas, os dispositivos comunicam entre si, ou com a infraestrutura, recorrendo a comunicações machine-to-machine (M2M). Uma vez que muitos destes dispositivos são simples, com escassa capacidade de processamento, foram desenvolvidos protocolos M2M como o Constrained Application Protocol (CoAP) e o Messaging Queue Telemetry Transport (MQTT), bem como frameworks de suporte de comunicações M2M. Apesar dos desenvolvimentos nesta tecnologia, ainda são encontrados desafios no desenvolvimento de aplicações M2M e IoT a nível da interoperabilidade, escalabilidade e padronização, por exemplo. Consequentemente, vários standards M2M foram desenvolvidos para superar estes desafios, sendo o oneM2M um deles. Atualmente, existem vários dispositivos disponíveis com uma interface WiFi embebida, o que significa que quando inseridos num sistema IoT, não necessitam de uma gateway (GW) para o acesso à Internet, uma vez que o WiFi é uma tecnologia omnipresente na sociedade atual. Esta é uma característica fundamental visto que diminui o custo global do sistema. Além disso, estes dipositivos, como o módulo ESP32, oferecem modos de poupança de energia que permitem explorar recursos de gestão de energia definidos pelo standard IEEE 802.11. As instituições de cuidados de saúde procuram oferecer os melhores serviços em termos de confiabilidade, segurança e conforto aos seus pacientes. Recentemente, tecnologias IoT foram abordadas, desenvolvidas e utilizadas para melhorar o serviço aos pacientes. O trabalho proposto nesta dissertação é um sistema de monitorização contínua via IoT capaz de monitorizar os sinais vitais de um paciente e apresentá-los aos profissionais de saúde. Para além disso, o sistema pode ser utilizado em diversos cenários desde salas de emergência, uso doméstico até à competição desportiva. O sistema possui dois componentes principais: um dispositivo wearable com uma antena WiFi e um sistema de monitorização orientado ao profissional de saúde. O wearable é composto por um sensor fotopletismográfico (PPG) MAX30100/MAX30102 para medir o ritmo cardíaco e os níveis de saturação de oxigénio no sangue, um ESP32 com uma antena WiFi incorporada para processar e enviar os dados do sensor para o sistema de monitorização e, finalmente, uma bateria de Lítio Polímero (LiPo) para fornecer energia aos dois componentes mencionados. No que refere ao sistema de monitorização, este é composto por uma base de dados orientada a eventos temporais para armazenar todos os dados necessários, um software de visualização gráfica para a visualização dos sinais vitais do paciente e, por fim, uma Interface Gráfica com o objetivo de ser um painel de controlo para todo o sistema. Para além disso, o sistema segue a norma oneM2M devido a questões de interoperabilidade relativas à arquitetura, e implementa o modelo de comunicação publisher-subscriber pois este é eficiente em termos de sensorização e monitorização remota. Por último, o objetivo desta dissertação é desenvolver um sistema de monitorização de baixo custo focado na gestão energética e que ao mesmo tempo não comprometa a sua confiabilidade e robustez.

Read accessible full text

Remote biometrical monitoring system via IoT

Author: Pedro de Castro Albergaria
Year: 2020
DOI: 10.34626/kc0h-rv95
Source: https://repositorio-aberto.up.pt/bitstream/10216/132783/2/411602.pdf
FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO
Remo e Biome ical Moni o ing Sys em
ia IoT
Ped o de Cas o Albe ga ia
Mes ado In eg ado em Engenha ia Ele o écnica e de Compu ado es
Supe iso : P o . D . Luís Miguel Pinho de Almeida
Second Supe iso : P o . D . Ped o Miguel Salguei o dos San os
July 30 h, 2020
© Ped o Albe ga ia, 2020
Resumo
As ins i uições de cuidados de saúde en am p o idencia os melho es se iços no que e e e
à iabilidade, segu ança e con o o dos seus pacien es. Nos úl imos anos, a ecnologia In e ne o
Things (IoT) em sido ado ada e desen ol ida pa a melho a es es se iços.
Os sis emas IoT êm egis ado um ápido c escimen o de ido à sua aplicabilidade em di e -
sos domínios, desde de cidades in eligen es a cuidados de saúde. Nes es sis emas, os diposi-
i os comunicam en e si, ou com a in aes u u a, a a és de comunicações machine- o-machine
(M2M). De ido ao ac o de que mui os des es disposi i os possuem poucos ecu sos compu a-
cionais, á ios p o ocolos M2M o am desen ol idos como o Cons ained Applica ion P o ocol
(CoAP) e o Messaging Queue Teleme y T anspo (MQTT). Exis em di e sos desa ios no desen-
ol imen o de aplicações M2M e IoT, en e eles a in e ope abilidade e s anda disa ion. Po isso,
á ios s anda ds M2M o am desen ol idos pa a esol e es es p oblemas, sendo o oneM2M um
deles. A ualmen e, há á ios disposi i os p esen es no me cado com uma an ena WiFi embebida, o
que pe mi e a in eg ação des es disposi i os num sis ema IoT sem a necessidade de um disposi o
com a uncionalidade de ga eway (GW) pa a a ligação à In e ne . O módulo ESP32 da Esp essi
é um dos módulos p esen es no me cado que supo a a ecnologia WiFi bem como possui modos
de mecanismo de poupança de ene gia elacionados com es a.
O abalho p opos o nes a disse ação consis e num sis ema IoT pon a-a-pon a baseado num
disposi i o de baixo cus o e baixo consumo que supo a a ecnologia WiFi capaz de moni o iza
con inuamen e os pa âme os isiológicos do usá io e ap esen á-los, po exemplo, a p o issionais
de saúde. O sis ema pode se aplicado em di e sos casos de uso como alas de eme gência e
compe ições despo i as.
O sis ema possui duas componen es p incipais: um disposi i o wea able baseado num mó-
dulo WiFi de baixo cus o e baixo consumo pa a o usuá io, e uma aplicação de moni o ização com
uma in e ace g á ica di ecionada aos p o issionais de saúde. O p imei o componen e é cons i-
uído po senso o ople ismog á ico MAX30102 pa a medi o ba imen o ca díaco e sa u ação de
oxigénio no sangue, um ESP32 pa a p ocessa e en ia os dados do usuá io pa a a aplicação de
moni o ização e, po úl imo, uma ba e ia de Lí io-políme o (LiPo) pa a o nece ene gia aos ou os
dois componen es. A aplicação de moni o ização é compos a po uma base de dados desenhada
pa a e en os empo ais (In luxDB) com a uncionalidade de a mazena os dados do sis ema, uma
e amen a de isualização de dados (Ch onog a ) e uma aplicação de moni o ização com uma
in e ace g á ica que se e como painel de con olo.
Adicionalmen e, o sis ema assen a no s anda d oneM2M e segue o modelo de comunicação
publicado -subsc i o de ido à e iciência des e na moni o ização emo a. Fo am implemen ados
e compa ados ês p o ocolos M2M: CoAP, HTTP e MQTT. De modo a a alia a pe o mance
do sis ema, o am conduzidas expe iências de la ência pon a-a-pon a (E2E), com ansmissão de
dados a di e en es equências, di e en es modos de poupança de ene gia do ESP32 e di e en es
p o ocolos de comunicação pa a dois canais de WiFi com qualidade de sinal di e en e. Os esul-
ados demons am que a la ência E2E pa a o canal de WiFi com má qualidade de sinal aumen a
i
ii
30.2% e 38.2% pa a mensagens publicadas com um pe íodo de 1 e 10 segundos com amanhos de
mensagem de 85B e 850B, espe i amen e, quando compa ado à la ência E2E expe ienciada po
um canal de WiFi com boa qualidade de sinal. É possí el conclui que os p o ocolos baseados em
TCP, como o HTTP e MQTT, expe enciam um aumen o da la ência E2E quando compa ados ao
CoAP, que é um p o ocolo baseado em UDP. Adicionalmen e, pa a as medidas com amanho de
mensagem de 850B, há uma aumen o da la ência E2E de 26.3% quando compa ada às medidas
de 85B en e os dois canais de WiFi. Po im, ela i amen e ao Packe Deli e y Ra io (PDR),
concluímos que es e é de 100% pa a o canal WiFi de boa qualidade de sinal, mas pa a o canal de
WiFi de má qualidade, o alo do PDR diminui quando ESP32 publica as mensagens em modos
de poupança de ene gia mais e icien es.
Nes a disse ação, oi desen ol ido um sis ema de moni o ização ocado no baixo cus o e
e iciência ene gé ica. No en an o, não comp omen e a iabilidade e obus ez de sis emas de moni-
o ização adicionais.
Pala as-cha e: Moni o ização Biomé ica, CoAP, HTTP, IoT, M2M, MQTT.
Abs ac
Heal hca e ins i u ions always s i e o p o ide he bes se ices conce ning he eliabili y,
sa e y and com o o he pa ien s. To do so, In e ne o Things (IoT) echnologies ha e been
emb aced and de eloped in ecen yea s o imp o e hese se ices.
IoT sys ems a e expe iencing apid g ow h due o hei applicabili y in se e al domains, om
sma ci ies o heal hca e, among many. In hese sys ems, de ices communica e wi h each o he ,
o wi h in as uc u e, eso ing o machine- o-machine (M2M) communica ions. Since many o
hese de ices a e esou ce-cons ained and ha e limi ed compu ing capabili ies, ligh weigh M2M
p o ocols we e de eloped such as Cons ained Applica ion P o ocol (CoAP) and Messaging Queue
Teleme y T anspo (MQTT) and accompanying amewo ks o suppo he ope a ion o he p o-
ocols, and p omo e in eg a ion wi h he a ge sys ems. The e a e challenges when de eloping
M2M and IoT applica ions: in e ope abili y, scalabili y, s anda disa ion, among o he s. Se e al
M2M s anda ds we e designed o add ess hese issues, wi h oneM2M being one o hem. Nowa-
days, he e a e mul iple de ices a ailable ha ha e an embedded WiFi in e ace, hus eschewing
he need o a GW in o de o be in eg a ed in a IoT a chi ec u e o access he In e ne since WiFi
is one o he mos common echnologies a In e ne bounda y. This is a key ea u e because i
inc eases he sys em’s pe asi eness while dec easing he o e all cos o he sys em. Addi ionally,
hese de ices, such as he Esp essi ESP32 module, o e powe managemen modes ha allow
exploi ing he powe managemen ea u es by he IEEE 802.11 s anda d.
The wo k p oposed in his disse a ion is an end- o-end IoT-inspi ed sys em based on small
o m- ac o , ul a-low powe and WiFi enabled embedded de ices capable o con inuously mon-
i o ing a use ’s i al signs and displaying hem, e.g., o medical pe sonnel. Such sys em can be
applied o a wide ange o applica ion scena ios om eme gency wa ds and home en i onmen o
spo s aining and compe i ion.
The sys em has wo majo componen s, a low-cos low-powe WiFi-enabled wea able de ice
o he use and a moni o ing applica ion o he medical pe sonnel. The wea able is composed by
a MAX30102 Pho oPle ysmoG aphy (PPG) senso o measu e he hea a e and oxygen sa u a ion
le els, an ESP32 wi h a buil -in WiFi an enna o p ocess and send he senso da a o he moni o ing
sys em and, inally, a Li hium Polyme (LiPo) ba e y o powe he p e ious wo componen s. The
moni o ing applica ion is composed o a ime-se ies da abase (In luxDB) o s o e all he da a, a
g aphics isualisa ion so wa e (Ch onog a ) o displaying use ’s i al signs and a moni o ing
applica ion wi h a G aphical Use In e ace (GUI) se ing as a con ol panel.
Addi ionally, he sys em elies on he oneM2M s anda d o he in e ope abili y conce ning
he a chi ec u e and ollows a publish-subsc ibe communica ion model due o i s e iciency in
sensing and emo e moni o ing. Also, we implemen and compa e h ee M2M p o ocols, namely
CoAP, HTTP and MQTT. To e alua e he sys em’s pe o mance, we conduc ed end- o-end (E2E)
la ency expe imen s, wi h da a ansmissions a di e en equencies, using he di e en powe
modes o e ed by he ESP32 module and di e en communica ion p o ocols o wo WiFi channel
quali y expe imen s ega ding signal s eng h. The esul s show ha he E2E la ency o a bad
iii

i
WiFi channel quali y inc eases 30.2% and 38.2% o messages published wi h 1 second and 10
seconds pe iods wi h 85B and 850B o payload, espec i ely, when compa ed o a good WiFi
channel quali y. We also conclude ha scena ios wi h TCP-based p o ocols, such as he HTTP
and MQTT, expe ience mo e E2E delay han UDP-based p o ocols, i.e. CoAP. Mo eo e , o he
850B o payload measu es, he e is an inc ease o 26.3% when compa ing o 85B o payload o
he wo channels expe imen s. Mo eo e , we conclude ha he PDR is 100% in he good channel
expe imen while in he bad expe imen he e is a dec ease o he PDR when he ESP32 is using
mo e ene gy-e icien powe modes.
Fu he mo e, in his disse a ion we de eloped a low-cos and ene gy-e icien moni o ing sys-
em while no comp omising he eliabili y and obus ness o adi ional machines and sys ems.
Keywo ds: Biome ical Moni o ing, CoAP, HTTP, IoT, M2M, MQTT.
Acknowledgemen s
Fi s , I would like show my g a i ude owa ds my supe iso s, P o esso Luís Almeida and
P o esso Ped o San os, o con inuously gi ing me suppo h oughou he all disse a ion p ocess.
I would also like o hank my amily, namely my pa en s, sis e s and g andmo he o all he
lo e and suppo .
To all my iends, a since e hank you o always being he e o me. Specially, I wan hank
o my colleague and dea iend Daniel Sil a, o his di ec in ol emen a he ea ly s ages o he
disse a ion.
Ped o de Cas o Albe ga ia
i
“Li e can only be unde s ood backwa ds;
bu i mus be li ed o wa ds”
So en Kie kegaa d
ii
xi LIST OF TABLES

Abb e ia ions and Symbols
ADC Analog- o-Digi al Con e e
ADN Applica ion Dedica ed Node
AE Applica ion En i y
ALP Applica ion Laye P o ocol
AP Access Poin
API Applica ion P og amming In e ace
AQMP Ad anced Queuing Message P o ocol
BPM Bea s Pe Minu e
CoAP Cons ained Applica ion P o ocol
CVD Ca dio ascula disease
CSE Common Se ice En i y
DDS Da a Dis ibu ion Se ice
DTIM Deli e y T a ic Indica ion Message
E2E End- o-end
GUI G aphical Use In e ace
HR Hea - a e
HTTP Hype ex T ans e P o ocol
I2C In e -In eg a ed Ci cui p o ocol
ID Iden i ie
IETF In e ne Enginee ing Task Fo ce
IoT In e ne O Things
LiPo Li hium-ion Polyme
Mbps Mega bi s pe seconds
MIPS Million Ins uc ions Pe Second
MQTT Message Queuing Teleme y T anspo
N/A No Admi ed
NSE Ne wo k Se ices En i y
OCF Open Connec i i y Founda ion
OS Ope a ing Sys em
PDR Packe Deli e y Ra io
PPG Pho oPle ysmoG aphy
QSPI Quad Se ial Pe iphe al In e ace
QoS Quali y o Se ice
TCP T anspo Con ol P o ocol
UDP Use Da ag am P o ocol
ULP Ul a-Low-Powe
URI Uni e sal Resou ce Iden i ie
RSSI Recei ed Signal S engh Indica ion
x
RTC Real-Time Clock
RTOS Real-Time Ope a ing Sys em
SCADA Supe iso y Con ol And Da a Acquisi ion
SCL Se ial Clock Line
SDA Se ial Da a Line
SDK So wa e De elopmen Ki
SoC S a e o Cha ge
SpO2Blood’s Oxigen Le el
STA S a ion
SHF Supe High F equency
WHO Wo ld Heal h O ganiza ion
XMPP Ex ensible Messaging and P esence P o ocol
Chap e 1
In oduc ion
1.1 Con ex and Mo i a ion
Acco ding o he Wo ld Heal h O ganiza ion (WHO), he global li e expec ancy inc eased all
o e he wo ld in he pas wo decades, om 67.5 yea s in 2000 o 72 yea s in 2016 [1]. This
inc ease s ems om be e heal hca e se ices o e ed o he mass popula ion. On he o he hand,
ca dio ascula diseases (CVDs), such as s okes and hea a acks, a e he main cause o dea h
oday, aking an es ima e o 17.9 million li es pe yea (which ep esen 31% o he wo ldwide
dea h oll) [2]. The indi iduals a isk o a CVD need con inuous ca e and moni o ing o hei
physiological pa ame e s.
In ecen yea s, new echnology solu ions ha e been de eloped o a mo e con enien way o
moni o ing pa ien ’s i al signs in hospi al en i onmen and a home, while o e ing he same qual-
i y o se ice. Namely, he In e ne o Things (IoT) echnological pa adigm has e ol ed apidly
o accommoda e his use case. Th oughou he yea s, nume ous IoT a chi ec u es ha e been p o-
posed o his domain, wi h small and com o able wea able de ices o acqui e i al signs om
he pa ien and display hem o he medical pe sonnel. Mo eo e , hese implemen a ions allow
he pa ien o be moni o ed om home h ough he In e ne , wi hou ha ing he need o go o he
hospi al o o he heal hca e acili y. Howe e , mos moni o ing applica ions in he ma ke wi h
wea ables de ices capable o con inuous moni o ing o physiological ely on sho - ange commu-
nica ion echnologies, ypically Blue oo h. This en ails he need o an ex a de ice an ex a de ice
( o example, a sma phone) se ing as a ga eway (GW) o sus ained In e ne connec ion h ough
ano he echnology, e.g., WiFi o cellula . Al hough he sma phones p esen enhanced connec-
i i y, he addi ional GW implemen a ion inc eases he powe consump ion o he de ice which
dec eases i s au onomy and poses an addi ional load bu den o he use .
The main mo i a ion o ca y ou o his disse a ion is he implemen a ion and assessmen
o an open IoT a chi ec u e o con inuous moni o ing applied o he eal- ime acking o he
physiological pa ame e s o he use s, such as he hea a e, and displaying he da a o medical
pe sonnel. We ollow he app oach p oposed in [3] elying on he ESP32 module ha includes
WiFi connec i i y and uns a ull TCP/IP, allowing o bypass he e e ed GW.
1
2In oduc ion
Figu e 1.1 illus a es an applica ion scena io in an eme gency wa d.
Hea -Ra e
Oxygen Le el Sa u a ion
Wi eless Link
WiFi-capable
Wea able In e ace
Da abase
Medical Pe sonnel
Figu e 1.1: Applica ion scena io in an eme gency wa d. Physiological pa ame e s (hea a e
and oxygen sa u a ion le els) a e collec ed by he wea ables om pa ien s and o wa ded o he
moni o ing sys em, whe e can be accessed by he medical pe sonnel.
1.2 Objec i es
The main objec i e o he wo k co e ed by his disse a ion is o implemen a eal- ime open
IoT a chi ec u e o con inuous moni o ing o physiological pa ame e s o he use s wi h low-cos
componen s and es he sys em in a spo s compe i ion game as well as home moni o ing. In
pa icula , de elop a WiFi-enabled wea able senso de ice based on he Esp essi ESP32 mod-
ule. The wea able de ice also con ains a MAX30102 Pho oPle hymosg aphy senso o acqui ing
hea - a e (HR) and blood’s oxygen le el (SpO2), and a LiPo o powe he o me componen s.
Addi ionally, he sys em mus p esen he pa ien da a o he medical pe sonnel, hus de eloping
a moni o ing applica ion wi h eal- ime da a is equi ed. Las ly, we conduc ed end- o-end (E2E)
la ency expe imen s o compa e he ESP32’s pe o mance in di e en powe modes by publishing
di e en message payloads o wo WiFi channel quali ies ega ding i ’s Recei ed Signal S eng h
Indica ion (RSSI), good signal s eng h channel and bad signal s eng h channel. Mo eo e , we
also assessed he Packe Deli e y Ra io (PDR) o he di e en channel expe imen s.
1.3 A chi ec u e
Figu e 1.2 p esen s he a chi ec u e o sys em he eby p oposed. A WiFi-enabled wea able de-
ice publishes use da a o he sys em’s b oke . Then, he b oke o wa ds he da a o he subsc ibe
1.4 Documen S uc u e 3
which is a moni o ing applica ion wi h GUI. A e ecei ing he da a, he moni o ing applica ion
s o es he da a in a da abase. Finally, o isualise he da a, we use a da a isualisa ion ool.
IN
Sys em's
b oke
Wea able De ice WiFi Access Poin
Moni o ing
Applica ion
wi h GUI
Da abase
CoAP, HTTP o MQTT
HTTP
HTTP
HTTP
Da a
Visualisa ion
Figu e 1.2: Sys em a chi ec u e
1.4 Documen S uc u e
This epo is a anged in six chap e s wi h he ollowing con en :
•Chap e 1p esen s he con ex and mo i a ion, objec i es and sys em’s a chi ec u e o his
disse a ion.
•Chap e 2 ocus on a eas-o -in e es in de eloping an IoT sys em such as M2M and IoT
applica ions de elopmen , low-powe WiFi and ela ed wo k o he disse a ion, among o h-
e s.
•Chap e 3discusses he a chi ec u e o he IoT moni o ing sys em as well as each compo-
nen , gi ing an insigh o i s cha ac e is ics and unc ion on he sys em.
•Chap e 4discusses he sys em’s implemen a ion and ope a ion.
•Chap e 5p esen s pe o mance esul s e e ed o E2E and PDR in he M2M communica-
ions.
•Chap e 6discusses he p ojec ’s inal conclusions and u u e wo k.

4In oduc ion
Chap e 2
IoT Implemen a ions on WiFi Nodes
This chap e co e s ou a eas o in e es o his disse a ion. Fi s , Sec ion 2.1 e iews M2M
and IoT applica ions de elopmen , in pa icula , middlewa e amewo ks, open-sou ce de elop-
men amewo ks, applica ions p o ocols and wi eless communica ion echnologies. Sec ion 2.2
in es iga es he ea u es o se e al embedded pla o ms wi h WiFi connec i i y o IoT applica-
ions such as ESP32 and W600-PICO modules. Se e al op ions ega ding ime-se ies da abases
and da a isualisa ion ools a e discussed in Sec ion 2.3. Finally, we conclude his chap e wi h
ela ed wo k o his disse a ion om IoT applica ions wi h he implemen a ion o he a o emen-
ioned s anda ds, amewo ks and ALPs in Sec ion 2.4.1 and he inno a i e use o w is -wo n
wea able de ices in he spo s domain in Sec ion 2.4.2.
2.1 M2M and IoT Applica ions De elopmen
As s essed ea lie , IoT echnologies and M2M ha e e ol ed apidly in ecen yea s. To e-
spond o his g ow h, amewo ks and M2M ALPs, as well as s anda ds, we e de eloped o p o ide
solu ions and imp o emen s in his a ea. In his sec ion, we will discuss se e al solu ions ega d-
ing middlewa e amewo ks, M2M amewo ks and pla o ms ( ocusing on open-sou ce p oduc s),
ALPs and wi eless communica ion echnologies in M2M and IoT applica ions de elopmen .
2.1.1 Middlewa e F amewo ks
This sec ion p esen s se e al open-sou ce middlewa e amewo ks. I gi es an o e iew o he
main ea u es and a chi ec u e.
2.1.1.1 AllJoyn
AllJoyn [4] is an open-sou ce middlewa e amewo k suppo ed by Open Connec i i y Foun-
da ion (OCF) ha ollows he clien -se e coope a ion model. Mic oso , Linux Founda ion,
Sony, Qualcomm a e some o he membe s o he o ganiza ion which suppo he amewo k.
AllJoyn uses an objec -o ien ed a chi ec u e o c ea e i s da a models and o e s bindings in Ja a,
5
6IoT Implemen a ions on WiFi Nodes
Objec i e-C, C++ and C [5]. Also, i is compa ible wi h mul iple ope a ing sys ems, e.g., Win-
dows, Linux, OS X, And oid.
The AllJoyn amewo k a chi ec u e is di ided in o ne wo k a chi ec u e and so wa e a chi-
ec u e. AllJoyn amewo k unc ions on he local ne wo k which allows de ice and apps disco -
e y. The e wo componen s: AllJoyn Apps (Apps o sho ) and AllJoyn Rou e s (Rou e s o
sho ). The e a e h ee common opologies, as illus a ed in Figu e 2.1 [6]:
Mobile App
App
App
Rou e
Rou e
App
Embedded
De ice
App
Embedded
De ice
Rou e
Rou e App
App
Figu e 2.1: AllJoyn amewo k’s ne wo k opologies
The so wa e a chi ec u e de ails he di e en componen s in he Apps and Rou e s ( e e o
Figu e 2.2). Apps con ain he ollowing componen s [6]:
•Co e Lib a y: Lowe le el APIs o in e ac ion wi h AllJoyn ne wo k;
•Se ice F amewo k Lib a ies: implemen s common se ice like con igu a ion, no i ica-
ions and con ol panel;
•App Code: s o e he applica ion logic.
Apps
App Code
Se ice
F amewo k
Lib a ies
Co e Lib a y
Rou e
Figu e 2.2: AllJoyn amewo k’s ne wo k componen s
A Rou e can un as s andalone de ice o is bundled wi h he AllJoyn Co e Lib a y.
2.1 M2M and IoT Applica ions De elopmen 7
Finally, he AllJoyn amewo k de ines wo a ian s. The S anda d e sion is o non-embedded
de ices (e.g., And oid and Linux) and he Thin e sion o esou ce-cons ained de ices (e.g., A -
duino and Linux wi h limi ed memo y).
2.1.1.2 FIWARE
FIMWARE [7] is an open-sou ce amewo k de eloped o imp o e and accele a e he de elop-
men o IoT solu ions, and i was ac i ely p omo ed by he Eu opean Communi y. I is suppo ed
by an independen Open Communi y whose membe s and con ibu o s aim o a s anda d ha is
sus ainable and easy o implemen in o de o build Sma Solu ions in a as e , easie and cheape
way [8]. Also, FIWARE has an API called FIMWARE NGSI which uses he Nex Gene a ion
Se ices In e ace (NGSI) wi h he goal o uni y he in o ma ion’s ep esen a ion [9]. Fu he -
mo e, his amewo k enables he in eg a ion o componen s and o e s he basis o he eplica ion
(po abili y) and in e ope abili y o his ield solu ions. I is a REST ul API ha p o ides an in u-
i i e G aphic Use s In e ace (GUI), suppo s subsc ip ion/no i ica ion and many o he ea u es.
The main and only manda o y componen o any pla o m based on FIWARE is he FIWARE
O ion Con ex B oke Gene ic Enable , p o iding se e al unc ions such as managing con ex in-
o ma ion, pe o ming upda es and b inging access o con ex ( e e o Figu e 2.3) [10]. Mo eo e ,
he e a e complemen a y FIWARE componen s a ailable wi h ega ds o IoT, API managemen
and p ocessing con ex in o ma ion, among o he s [10]:
Con ex
P ocessing, Analysis,
Visualisa ion
Co e Con ex Managemen
(Con ex B oke )
In e ace o
IoT, Robo ics and hi d pa y
sys ems
Da a/API Managemen
Publica ion
Mone isa ion
Deploymen
ools
Figu e 2.3: Gene al solu ion wi h a FIWARE pla o m
2.1.1.3 IoTi i y
IoTi i y [11] is an open-sou ce and esou ce-o ien ed a chi ec u e amewo k suppo ed by
OCF which connec s IoT de ices, enabling and p o iding unc ions o disco e y, connec ion and
messaging among hem [12]. M2M communica ions a e suppo ed h ough CoAP. Mo eo e , he
subjec i e amewo k suppo s a connec i i y abs ac ion laye . As a esul , he API is a ailable in
mul iple ne wo k echnologies such as WiFi, E he ne and Blue oo h and i is a ailable o Linux,
Windows, And oid, A duino, among o he s. Mo eo e , he API is a ailable Ja a, C and C++
APIs. IoTi i y amewo k con ains h ee laye s o di e en pu poses: he se ice laye o e sees
de ice managemen , no i ica ion and Resou ce Con aine , among o he s; he base laye is in cha ge
14 IoT Implemen a ions on WiFi Nodes
2.1.3.4 MQTT
MQTT is a ligh weigh and one o he oldes M2M communica ion p o ocols de eloped by
IBM and in oduced in 1999 [31,32,29]. The p o ocol ollows a opic-based publish-subsc ibe
a chi ec u e designed and op imised o high-la ency and cons ained ne wo k [35,36]. Analogous
o HTTP, MQTT uses TCP as i s anspo laye p o ocol.
As s essed ea lie , he p o ocol ollows a opic-based publish-subsc ibe model which means
ha each message is associa ed wi h a opic. The publishe en i y sends he messages o a b oke ,
which ac s as an in e media y and o wa ds he messages o he en i ies ha subsc ibed o he
message’s opics.
MQTT o e s h ee di e en le els o QoS ega ding message deli e y [37]:
•QoS 0 (a mos once deli e y): This o e s he inhe en message deli e y eliabili y o he
TCP p o ocol. In his le el, he message a i es a he ecei e o does no a i e a all. The
sende does no e y o send he message and he e is no esponse message by he ecei e ;
•QoS 1 (a leas once deli e y): This QoS le el ensu es ha he message is deli e ed a leas
once o he ecei ing en i y. The ecei e has o send a con i ma ion message o he sende o
in o m ha he message was deli e ed. I he sende doesn’ ecei e a con i ma ion message
a e a imeou , he message is esen ;
•QoS 2 (exac ly once deli e y): This QoS le el ensu es ha he e a e no duplica e messages
o message loss. Bo h en i ies send con i ma ion messages o ensu e ha he message is
deli e ed exac ly once o he ecei e en i y.
As expec ed, communica ion eliabili y inc eases wi h he le els o QoS. Howe e , he e is
mo e la ency and bandwid h consump ion associa ed wi h highe QoS le els.
2.1.3.5 Ex ensible Messaging and P esence P o ocol
Ex ensible Messaging and P esence P o ocol (XMPP) is a p o ocol based on ex ensible ma kup
language (XML) de eloped by IETF. Analogous o AQMP and MQTT, i is designed o message-
o ien ed middlewa e [5]. XMPP is based on TCP p o ocol wi h XML S anzas and suppo s eal-
ime communica ion be ween a se e and a clien . The p o ocol ollows bo h publishe /subsc ibe
and eques / esponse pa e ns [31].
2.1.3.6 P o ocol’s Compa ison and E alua ion
In he ollowing able, a compa a i e analysis be ween he p e iously men ioned p o ocols is
p esen ed:

2.1 M2M and IoT Applica ions De elopmen 15
Table 2.1: Compa a i e analysis o applica ion p o ocols in IoT sys ems
P o ocol Abs ac ion A chi ec u e Quali y o Se ice T anspo P o ocol
AQMP Publish/Subsc ibe
Reques /Response
Clien /B oke
Clien /Se e
Se le Fo ma
Unse le Fo ma TCP
CoAP Publish/Subsc ibe
Reques /Response
Clien /B oke
Clien /Se e
Con i mable
Non-con i mable UDP
HTTP Reques /Response Clien /Se e N/A TCP
MQTT Publish/Subsc ibe Clien /B oke QoS0, QoS1, QoS2 TCP
XMPP Publish/Subsc ibe
Reques /Response Clien /Se e N/A TCP
Du ing he las decade, due o he g ow h o M2M communica ions and IoT applica ions, he e
has been in ensi e esea ch and s udy o M2M communica ion p o ocols pe o mance in di e en
applica ions scena ios wi h di e en echnologies and ne wo k condi ions, o example. The e o e,
Table 2.2 shows ele an s udies ega ding he p o ocols p e iously men ioned, among o he s. I
is wo h no icing ha he able ollows he s uc u e p esen ed in Re e ence [32].
Table 2.2: Compa ison s udy abou ALPs in p e ious wo ks
Au ho s P o ocols Me ics Pu pose Resul s
Bandyopadhyay
e al. [35] (2013)
CoAP,
MQTT
Powe con-
sump ion by
inc easing pay-
load size and
changing he
condi ions o
packe loss e-
ga ding payload
size
S udy p o ocol’s
pe o mance
ega ding ene gy
e iciency using
Cons ained
Ga eway De ices
CoAP is he
mos e icien in
e ms o ene gy
comsup ion and
bandwid h
Fysa akis e
al. [36] (2016)
CoAP,
DPWS,
MQTT
Clien esponse
ime o a eques ,
A e age CPU
Load and A -
e age Memo y
U ilisa ion
E alua e he
p o ocols in he
same es bed o
ex ac conclu-
sions conce ning
pe o mance
DPWS showed
he wo s esul s
in wo ca ego ies
(clien esponse
ime and memo y
u ilisa ion), ol-
lowed by MQTT
(CPU load).
16 IoT Implemen a ions on WiFi Nodes
Chen e al. [31]
(2016)
CoAP,
Cus om
UDP, DDS,
MQTT
Bandwid h
consump ion, la-
ency and packe
loss
Conduc a s udy
o illus a e
how p o ocols
unc ion how
p o ocols unc-
ion unde a
cons ained, low
quali y wi eless
ne wo ks
TCP-based p o-
ocols a e mo e
eliable and ha e
mo e la ency
expe ienced
han UDP-based
p o ocols
Kayal e al. [38]
(2017)
CoAP,
MQTT,
XMPP,
WebSocke
Response ime by
a ying he a ic
load on he ne -
wo k
Measu es p o-
ocols’ pe -
o mance in
cons ained de-
ices o ensu e
e iciency
CoAP pe o ms
be e han o he
p o ocols o
highe se e
u ilisa ion.
XMPP pe o ms
be e han o he s
a lowe se e
u ilisa ion
Hedi e al. [39]
(2017)
CoAP,
MQTT
By es sen and
ime needed o
ecei e hem
E alua e pe o -
mance and com-
pa e he p o o-
cols in di e en
scena ios
Concludes ha
CoAP is a good
choice whe e
eal- ime pe -
o mance and
la ency a e no
equi emen s
2.1 M2M and IoT Applica ions De elopmen 17
Naik [29]
(2017)
AMQP,
CoAP,
HTTP,
MQTT
Message Size
s Message
O e head, Powe
Consump ion
s Resou ce
Requi emen ,
among o he s
In-dep h and el-
a i e analysis o
he p o ocols o
gain insigh in o
hei s eng hs
and limi a ions
HTTP is he i s
( i.e, wi h high-
es ) in message
size, message
o e head, powe
consump ion and
la ency while
CoAP is he
lowes . MQTT
is he highes in
eliabili y and
AQMP is highes
in secu i y and
p o isioning, o
example.
Pohl e al. [40]
(2018)
AMQP,
MQTT,
XMPP
La ency,
Th oughpu ,
Bandwid h Us-
age, Reliabili y
and Ene gy
Consump ion
Measu es p o-
ocols’ pe o -
mances ega ding
a iable la ency
and Packe -Loss-
Ra e (PLR)
MQTT pe o ms
bes ega ding
he cha ac e is-
ics bandwid h
usage, elia-
bili y, la ency
and h ough-
pu . AMQP
pe o ms wo se
han MQTT
compa ing he
bandwid h usage
and h ough-
pu . In con as ,
XMPP has he
wo s alues in
all ca ego ies
18 IoT Implemen a ions on WiFi Nodes
Pa elic e
al. [41] (2018)
CoAP,
HTTP,
MQTT
Measu ing en-
e gy and powe
Consump ion
sending da a and
s andby
Measu ing
p o ocols’ pe -
o mance by
sending da a
and b ing in a
s andby posi ion
ega ding en-
e gy and powe
consump ion
CoAP and
MQTT p e-
o med signi i-
can ly be e han
HTTP. CoAP and
MQTT consume
almos equal
amoun s o en-
e gy o sending
da a
Ço ak e al. [32]
(2018)
CoAP,
MQTT,
XMPP
Measu e packe
c ea ion ime
and packe
ansmission
ime
Collec eal- ime
en i onmen-
al da a wi h
a eal-wo ld
es bed
XMPP is wo se
han o he p o-
ocols in bo h
me ics and
MQTT and
CoAP pe o m
almos equally
2.1.4 Wi eless Communica ion Technologies
In ecen yea s, wi eless communica ion echnologies ha e eme ged o espond o M2M com-
munica ions equi emen s. Some echnologies allow long- ange communica ions and high da a
ansmission a es, while o he s aim o sho - ange M2M communica ions wi h low da a ansmis-
sion a es. In his wo k, we ocus and gi e an o e iew o sho - ange wi eless communica ion
echnologies because hese echnologies a e he mos ele an o an online moni o ing sys em.
2.1.4.1 Blue oo h
Blue oo h, s anda dised as IEEE 802.15.1, is a wi eless communica ion echnology de eloped
as an al e na i e o wi e-based communica ion echnologies. Since he i s consume Blue oo h
de ice launch in 1999, he s anda d is con inuously e ol ing o adap o he inc easing echnology
equi emen s, playing a majo ole in M2M communica ions nowadays.
Blue oo h de ices ope a e in he 2.4GHz ISM spec um band and use 79 o i s channels. As
o now, he s anda d de ines ou de ice classes di e en ia ing ansmission powe and ange.
Rega ding a chi ec u e, Blue oo h ollows a mas e /sla e a chi ec u e, and each mas e can connec
a he same ime o se en sla es de ices a mos in a picone ne wo k.
Al hough se e al online moni o ing sys ems implemen a ions a e using Blue oo h has i s sho -
ange M2M communica ions echnology, he s anda d allows ne wo ks wi h ew de ices, which
makes i unsui able o mo e ambi ious moni o ing sys ems in e ms o scale. Mo eo e , he high
s a up imes o connec o a new de ice and i s high ene gy consump ion a e no adequa e o his
2.2 Low-Powe WiFi Nodes 19
use case. The in oduc ion o he low-ene gy consump ion e sion, Blue oo h Low Ene gy [42],
makes he s anda d mo e sui able o his ype o sys ems. Finally, a Blue oo h-based sys em
no mally needs a GW de ice (p.e., a Sma phone) o connec o he In e ne , which ypically uses
WiFi a i s bo de .
2.1.4.2 Zigbee
ZigBee is a low-powe communica ion p o ocol o pe sonal a ea ne wo ks wi h small and
low-powe de ices such as home au oma ion, da a collec ion o medical pe sonnel and o he
small p ojec s. Zigbee ope a es in 2.4GHz, which can be an issue due o i s o e lap wi h WiFi
and o he echnologies. Addi ionally, he s anda d o e s low da a ansmission a es and limi ed
suppo o QoS. The connec ion o he In e ne is no mally achie ed h ough a GW node.
2.1.4.3 WiFi
The IEEE 802.11 p o ocol, mo e commonly known as WiFi, allows he c ea ion o a Wi eless
Local A ea Ne wo k and p o ides In e ne access. The echnology o e s secu e, eliable and as
wi eless connec i i y be ween de ices. WiFi is p esen in he a ious scena ios in oday’s socie y,
such as o ice spaces, comme cial a eas and homes.
The ne wo k ope a es in 5GHz o Supe High F equency (SHF) and 2.4GHz ISM spec um
bands while p o iding In e ne connec i i y h ough APs.
In ecen yea s, wi h he eme gence o small WiFi-enabled low-powe de ices, mo e moni-
o ing sys ems use his echnology as i s M2M communica ion p o ocol. Mo eo e , he s anda d
o e s powe managemen ea u es which makes i sui able o sys ems wi h low-powe equi e-
men s. As opposed o Blue oo h, sys ems wi h WiFi echnology does no need a GW de ice o
an In e ne connec ion.
2.2 Low-Powe WiFi Nodes
Nowadays, he e is a as choice ega ding embedded pla o ms wi h WiFi connec i i y [43].
Al hough mul iple de ices a e a ailable in he ma ke , he e a e disc epancies conce ning wi eless
communica ion in e aces (e.g, Blue oo h, WiFi and Zigbee), compu a ional powe , cos and en-
e gy consump ion as well as physical oo p in [43]. The ESP32 and he W600-PICO a e some
o he modules a ailable on he ma ke wi h WiFi connec i i y which can be easily applied o IoT
applica ions [44,45]. In he ollowing sec ions we co e he main ea u es o hese modules ha
a e pa icula ly in e es ing o IoT applica ions.
2.2.1 ESP32 Module
ESP32 is an ul a-low-powe solu ion designed o mobile, wea able de ices and, mo e im-
po an ly, o IoT applica ions [44]. The module con ains he ollowing ea u es ha make i a
highly-in eg a ed solu ion o IoT applica ions [44]:

20 IoT Implemen a ions on WiFi Nodes
• S anda d IEEE 802.11 b/g/n and IEEE 802.11 n (2.4 GHz, up o 150 Mbps) compliance
wi h on-boa d an enna;
• WPA/WPA2 secu i y p o ocols;
• X ensa® single-/dual-co e 32-bi LX6 mic op ocesso s(s), up o 600 MIPS;
• 520kB in e nal SRAM and 16MB ex e nal QSPI lash;
• Fi e buil -in powe modes suppo ed;
• 25x18 mm;
• Low-cos de ice, when compa ed o o he WiFi modules.
Conce ning he 32-bi p ocesso , i p o ides compu ing powe enabling he ollowing ea u es,
which eases he de elopmen o IoT applica ion [43]:
• Real-Time Ope a ing Sys em (RTOS);
• In as uc u e s a ion, So AP and P omiscuous modes [44];
• Comple e TCP/IP p o ocol s ack.
2.2.2 W600-PICO Module
W600-PICO module is a de ice wi h an WiFi connec i i y ha can be easily applied o IoT
applica ions such as sma appliances, sma homes and heal hca e [45]. This de ice has he
ollowing ea u es [45]:
• S anda d IEE 802.11 b/g/n/e/i/d/k/ /s/w compliance wi h on-boa d an enna;
• WPA/WPA2/WPS secu i y p o ocols;
• Suppo s WiFi WMM/WMM-PS;
• A m® Co ex M-3 32-bi p ocesso wi h 80 MHz ope a ing equency;
• 288 KB in e nal RAM and 1MB/2MB in e nal lash;
• 33x20.3 mm;
Simila o he ESP32 module, he W600-PICO 32-bi p ocesso p o ides compu ing powe
enabling he ollowing ea u e:
• Real-Time Ope a ing Sys em;
• Suppo s AP and STA modes;
Rega ding powe managemen , W600-PICO suppo s PS-Poll and U-APSD de ined by he
IEEE 802.11 s anda d [45]. I is wo h no icing when in s andby, W600-PICO powe consump ion
is less han 10 µA [45].
2.3 Time Se ies Da abases and Da a Visualiza ion Tools 21
2.2.3 WiFi Nodes Compa ison
Table 2.3 p esen s he main ea u es o he ESP32 and W600-PICO modules ha ease he
de elopmen o IoT applica ions.
Table 2.3: Main ea u es o he ESP32 and W600-PICO modules
Fea u e ESP32 W600-PICO
WiFi
S anda d IEEE 802.11 b/g/n and
IEEE 802.11 n (2.4 GHz, up o
150 Mbps) compliance wi h on-
boa d an enna
S anda d IEEE 802.11
b/g/n/e/i/d/k/ /s/w compliance
wi h on-boa d an enna
Secu i y P o ocols WPA/WPA2 secu i y p o ocols WPA/WPA2/WPS secu i y p o-
ocols
P ocesso s X ensa® single-/dual-co e 32-bi
LX6 mic op ocesso s(s)
A m® Co ex M-3 32-bi p oces-
so wi h 80 MHz ope a ing e-
quency
Memo y 520kB in e nal SRAM and
16MB ex e nal QSPI lash
288 KB in e nal RAM and
1MB/2MB in e nal lash
Powe Managemen
Fou buil -in sleep modes sup-
po ed wi h minimum cu en
consump ion o 10 µA
PS-Poll and U-APSD de ined by
he IEEE 802.11 s anda d. In
s andby he powe consump ion
is less han 10 µA
Dimensions 25x18 mm 33x20.3 mm
2.3 Time Se ies Da abases and Da a Visualiza ion Tools
An IoT moni o ing sys em can collec and s o e housands o e en millions o da a ins ances
o e a sho pe iod. The e o e, da a p ocessing, managemen and isualisa ion a e key aspec s o
an IoT moni o ing sys em. In his sec ion, we p esen h ee al e na i es ha accomplish he o me
aspec s: In luxDB and Ch onog a , P ome heus and G a ana and, inally, Thinge .io.
2.3.1 In luxDB and Ch onog a
In luxDB [46] is an open-sou ce ime-se ies da abase buil o handle high w i e and que y
loads. The da abase is one o he ou componen s ha o m he TICK (Teleg a , In luxDB,
Ch onog a , Kapaci o ) s ack. In luxDB is a da abase o use cases ha in ol e la ge amoun s
o imes amped da a such as IoT senso da a moni o ing and eal- ime analy ics [47]. I cu en ly
suppo s se e al key ea u es ha a e use ul and impo an imes amped da a-cen ed sys em [47]:
• Cus om designed da as o e o ime se ies da a;
• W i en exclusi ely in Go and compiles in o a single bina y ile wi hou ex e nal dependen-
cies;
• O e s high pe o ming w i e and que y HTTP APIs;
22 IoT Implemen a ions on WiFi Nodes
• De eloped o que y agg ega ed da a wi h an SQL-like language;
• Da a e en ion policies.
Ch onog a [48] is he use in e ace o he In luxDB 1.x pla o m wi h he pu pose o allow
he use s o see da a s o ed in he da abase wi h ease. The so wa e includes empla es and lib a ies
o build dashboa ds wi h eal- ime isualisa ions o da a. Toge he wi h Kapaci o [49], i is pos-
sible o c ea e di e en ypes o ale s o de ec ing anomalies in he s o ed da a and see he ale s
his o y in he Ch onog a use in e ace. Figu e 2.10 illus a es he TICK s ack and i s beha iou
model:
Figu e 2.10: TICK s ack [46]
2.3.2 P ome heus and G a ana
P ome heus [50] is an open-sou ce da abase designed o sys ems ha ely on imes amped
da a c ea ed SoundCloud. P ome heus main ea u es a e he ollowing [51]:
• Does no ely on dis ibu ed s o age, single se e nodes a e au onomous;
• Da a collec ion ia HTTP pull model;
• Mul iples modes o g aphic isualisa ion and suppo ;
• A lexible que y language, P omQL, o que y agg ega e da a;
• W i en p ima ily in Go.
Figu e 2.11 illus a es he P ome heus a chi ec u e and some o i s p ima y componen s, many
o which can be eplaced by o he ools:
G a ana [52] is he ool o eal- ime da a isualisa ion s o ed in P ome heus, analogous o
wha Ch onog a is o In luxDB. G a ana o e s empla es and lib a ies o buil cus om dashboa ds
as well as an ale managemen sys em [53].
2.3 Time Se ies Da abases and Da a Visualiza ion Tools 23
Figu e 2.11: P ome heus a chi ec u e [51]
2.3.3 Thinge .io
Thinge .io [54] is an open-sou ce cloud pla o m specially designed o IoT a chi ec u es.
The pla o m consis s o a Backend (which is he IoT se e ) and a web-based F on end o bo h
compu e and sma phone o manage all he a ailable ea u es. Thinge .io has he ollowing key
ea u es [55]:
• Ha dwa e agnos ic, which means ha any p oduc , independen o he manu ac u e , is eas-
ily deployable and in eg a ed;
• E icien , e icien and a o dable ways o s o e de ice da a as well as eal- ime da a agg e-
ga ion;
• Real- ime da a isualisa ion h ough dashboa ds;
• Ale managemen sys em.
Figu e 2.12 shows he main componen s o a Thinge .io ecosys em:
Figu e 2.12: Thinge .io a chi ec u e [55]
30 Componen s o he IoT Moni o ing Sys em
The e a e i e a ia ions o he ESP32 chip, which p ima ily di e en ia e wi h he numbe o
CPU co es (one o wo), MIPS alue and whe he he e is embedded lash memo y o no :
• ESP32-DOWDQ6;
• ESP32-D0WD;
• ESP32-D2WD;
• ESP32-S0WD;
• ESP32-PICO-D4.
Fo his p ojec , we chose ESP32-D2WD chip because i has a dual-co e CPU p ocesso wi h
600 MIPS and a 16 MB embedded lash memo y. This pa icula chip o e s se e al ea u es ha
make i highly in eg able wi h IoT applica ions [44]:
• Small size (25 x 18 mm), ideal o wea able de ices, o example;
• Suppo s IEEE 802.11 b/g/n and IEEE 802.11 n (2.4 GHz, up o 150 Mbps) compliance wi h
on-boa d an enna, which enables sensing applica ions wi h an In e ne connec ion wi hou
a GW de ice;
• Suppo WPA/WPA2 secu i y p o ocols o a secu e WiFi connec ion;
• Powe managemen ea u es such as mul iples powe modes and dynamic powe scaling;
• Two 32-bi p ocesso s, wi h low-powe consump ion and wi h a maximum ope a ing e-
quency o 240 MHz (X ensa® dual-co e 32-bi LX6 mic op ocesso s(s)).
• Suppo s a eal- ime ope a ing sys em (F eeRTOS);
• O e s h ee WiFi ope a ing modes: In as uc u e S a ion, So AP and P omiscuous;
• Full TCP/IP s ack implemen a ion;
• In eg a es 520kB in e nal SRAM and 16MB ex e nal QSPI lash;
• Low-cos de ice, when compa ed o o he WiFi modules.
The Esp essi IoT De elopmen F amewo k, also know as ESP-IDF, is he o icial SDK o
he ESP32 amily se ies. I has suppo o Windows, Linux and Mac OS. ESP-IDF p o ides
he de elope s wi h a F eeRTOS-based API [67], w i en in C, o help hem do de elop applica-
ions wi h ease. Fu he mo e, Esp essi Sys em p o ides up- o-da e API documen a ion [68] and
p ac ical examples o he di e en API unc ionali ies.
We chose he ESP32 as he wea able’s mic ocon olle due o i s cha ac e is ics ha make i a
easily deployable module o IoT applica ion, namely a 32-bi dual-co e mic op ocesso , suppo
o i e buil -in powe modes and RTOS, and a comple e TCP/IP p o ocol s ack.

3.2 Wea able 31
3.2.1.1 Low-powe Managemen
As s essed ea lie , his module o e s i e powe modes which enable he CPU, he WiFi
in e ace and o he pe iphe als o shu down o inac i i y pe iods [44].
The Ac i e mode is he de aul mode whe e he CPU, WiFi in e ace and o he pe iphe als a e
enabled. Thus, i is no ideal o use his mode i he applica ion equi es low-powe consump ion.
In Modem-sleep mode, he CPU is ope a ional and he clock equency is con igu able. The
WiFi ci cui is shu down al hough he associa ion o ne wo k AP is main ained, hus a oiding
he need o econnec upon waking and he espec i e high la ency [43]. Addi ionally, Esp essi
de ines wo a ian s o he Modem-sleep,Minimum Modem sleep and Maximum Modem sleep,
only i he module wo ks in s a ion mode [69]:
•Minimum Modem sleep: he de ice wakes up e e y Deli e y T a ic Indica ion Message
(DTIM) o ecei e a beacon. B oadcas da a will no be los because i ansmi ed a e
DTIM. Howe e , i he DTIM is sho , he e is no ha much powe sa ing;
•Maximum Modem sleep: he de ice wakes up e e y beacon lis en in e al. B oadcas da a
can be los because he de ice can be in a sleep s a e a DTIM ime. In his mode, he e is
less powe consump ion i he beacon lis en in e al is longe , al hough he b oadcas da a
can be easily los .
The Ligh -sleep mode pauses he CPU while keeping he RTC memo y, he RTC pe iphe als
and he ul a-low-powe (ULP) co-p ocesso a e unning. The WiFi in e ace is shu down and he
associa ion o he ne wo k AP is p ese ed because he module p ese es i s in e nal s a e. This
is no ideal o applica ions ha send WiFi da a pe iodically because he wake ime du a ion, hus
da a can be los .
The Deep-sleep mode is simila o he Ligh -sleep mode. The main di e ence is ha he CPU
is inac i e and WiFi connec ion da a is s o ed in he RTC memo y.
Finally, in he Hibe na ion mode, all componen s a e shu down, including he in e nal 8MHz
oscilla o and ULP p ocesso , excep one RTC ime and some RTC GPIOs. The e o e, he de ice
canno p ese e any kind o memo y.
Table 3.1 and 3.2 con ains he p ope ies o he mul iple powe modes and he ypical cu en
consump ion conce ning each powe mode o ESP32 chip used in his wo k, espec i ely.
Table 3.1: ESP32 powe modes’ ha dwa e le el dis inc ion
I em Modem-sleep Ligh -sleep Deep-sleep Hibe na ion
WiFi In e ace OFF OFF OFF OFF
AP Associa ion Connec ed Connec ed Disconnec ed Disconnec ed
Sys em Clock ON OFF OFF OFF
RTC ON ON ON Mos OFF
CPU ON Pending OFF OFF
32 Componen s o he IoT Moni o ing Sys em
Table 3.2: Sleep-modes’ ypical cu en consump ion s a ed in he da ashee [44]
Powe Mode Desc ip ion Powe Consump ion
Ac i e
T ansmi 802.11b 240 µA @ 50% du y
T ansmi 802.11g 190 µA @ 50% du y
T ansmi 802.11n 180 µA @ 50% du y
Recei e 802.11b/g/n 95 mA ∼100 mA @ 50% du y
Modem-sleep CPU is powe ed on
240 MHz 30 mA ∼68 mA
160 MHz 27 mA ∼44 mA
80 MHz 20 mA ∼31 mA
Ligh -sleep - 0.8 mA
Deep-Sleep
The ULP co-p ocesso is powe ed on 150 µA
ULP senso -moni o ed pa e n 100 µA @ 1% du y
RTC Time + RTC memo y 10 µA
Hibe na ion RTC Time only 5 µA
3.2.2 MAX30102 Senso
The MAX30102, he successo o he MAX30100 and MAX30101, is an highly in eg a ed
HR moni o and pulse oxime e senso in a LED e lec i e solu ion sui able o wea able de ices
de eloped by Maxim In eg a ed. I has he pu pose o acqui e HR and SpO2.
The senso con ains wo LEDs ( ed and in a ed wi h 660nm and 880nm o wa eleng h, e-
spec i ely), pho ode ec o s, co e glass o op imal pe o mance and low-noise elec onics o can-
celling ambien ligh . The module ope a es on a 3.3V powe supply. I p o ides ul a-low-powe
op ions wi h p og ammable sample a e and LED cu en as well as a s andby mode ha has an in-
signi ican cu en consump ion. Communica ion be ween he MAX30102 and a mic ocon olle
is ia In e -In eg a ed Ci cui p o ocol (I2C). Addi ionally, he senso includes a disc e e- ime il e
o ejec 50Hz/60Hz noise.
3.2.2.1 Regis e s
The MAX30102 is ully cus omised by w i ing he 8-bi s in e nal egis e s. Table 3.3 gi es an
o e iew o he p ima y egis e s.
The FIFO is ci cula and can s o e up o 32 samples, which is equi alen o 196 by es (6 by es
pe sample). As shown in Figu e 3.3, he FIFO da a is le -jus i ied, he e o e he bi 17 always
holds he mos signi ican bi . Figu e 3.4 shows he s uc u e o each iple o by es (con aining
he 18-bi ADC da a o each LED channel) and isual p esen a ion o how he samples a e s o ed
in he FIFO da a s uc u e.
3.3 Moni o ing Applica ion wi h GUI
The moni o ing applica ion con ols he da a low be ween he main componen s o he sys em.
Thus, ecei ing and sending da a o he ESP32 h ough OM2M b oke , and upda ing he In luxDB
wi h ESP32 da a and log ac i i y.
3.3 Moni o ing Applica ion wi h GUI 33
Table 3.3: O e iew o he MAX30102’s egis e s
Regis e s (Add ess) Desc ip ion
FIFO W i e Poin e (0x04) Poin s o he loca ion whe e he senso w i es he
nex sample
O e low Coun e (0x05)
Coun s he numbe o los samples. When he
FIFO is ull, samples a e no pushed in o he
FIFO, samples a e los
FIFO Read Poin e (0x06) Poin s o he loca ion whe e he p ocesso ge s
he nex sample om he FIFO h ough I2C
FIFO Da a Regis e (0x07) S o es 8 bi s o sample da a
FIFO Con igu a ion (0x08) Se sample a e aging and o he FIFO be-
ha iou al con igu a ions
Mode Con igu a ion (0x09)
Con igu e ope a ing modes o he senso : Hea
Ra e mode (Red LED only), SpO2mode and
Mul i-LED mode (RED and IR)
SpO2Con igu a ion (0x0A) Con igu e SpO2ADC ange con ol, sample a e
and LED pulse wid h
LED Pulse Ampli ude (0x0C - 0x0D) Se cu en le el o Red LED (0x0C) and IR
LED (0x0D)
Mul i-LED Mode Con ol (0x11 - 0x12)
In mul i-LED mode, each sample is spli in o
ou ime slo s. These egis e s de e mine which
LED is ac i e in each ime slo
Figu e 3.3: Sample da a s o ed in FIFO da a s uc u e [70]
Along wi h he moni o ing applica ion, he e is a GUI ha allows he use o con ol he sys em.
Bo h he moni o ing applica ion and GUI we e de eloped in Ja a due o compa ibili y wi h he
OM2M b oke (also a Ja a implemen a ion).
The GUI in e ace comp ises wo pages en i led "S a Page" and "Main Page". The "S a
Page", shown in Figu e 3.5 is an in oduc o y page wi h he p ojec ’s i le and a single "S a " bu -
on. This bu on, when clicked, s a s he sys em by ini ialising communica ion wi h he In luxDB
and he OM2M b oke , hus enabling he connec ion wi h wea ables.
The "Main Page" o e s eal- ime in o ma ion and bu ons o con ol he sys em. The use
can add, pause, emo e and dele e a single wea able o add and emo e all wea ables a he same
ime. The ables "T ansmi ing Wea ables Table" and "Paused Wea ables Table" gi e in o ma ion
on whe he a wea able is sending da a (ac i e wea ables) o no (paused wea able). Finally, he
34 Componen s o he IoT Moni o ing Sys em
Figu e 3.4: FIFO da a s uc u e [70]
Figu e 3.5: GUI’s "S a Page"
bu on "Ch onog a " opens a b owse page whe e he use can isually see all he da a ega ding a
wea able, and he "Res a " es a s he p og am. Figu e 3.6 p esen s he "Main Page".
3.4 In luxDB
IoT moni o ing sys ems can gene a e la ge amoun s o imes amped da a in sho pe iods o
ime, hus using a da abase speci ically buil o ime-se ies da a is an ad an age. F om he solu-
3.4 In luxDB 35
Figu e 3.6: GUI’s "Main Page"
ions p oposed in Sec ion 2.3, In luxDB [46] is he s andou due o i s easy o ind and a ailable
documen a ion. The e o e, we use his solu ion o s o e all he da a gene a ed by he sys em due
o i s capabili y o handle imes amped da a wi h high pe o mance, i s speci ic design o an IoT
senso da a, w i e and que ying Ja a HTTP APIs (Ja a is he p og amming language o he uppe -
le el end o he sys em) and SQL-like que y language, In luxQL, de eloped o que y agg ega ed
da a. sys em [47].
All In luxDB’s da a ha e an associa ed imes amp, he e o e he e is a column ime o e e y
In luxDB ins ance. This column s o es he imes amp agg ega ed wi h he da a up o nanosecond
p ecision. Da a con en such as HR alues in bea s pe minu e (bpm), is s o ed in ield alues,
which can be s ings, loa s, in ege s o booleans. A ield alue is always associa ed wi h a imes-
amp. Field keys a e s ings ha ield alues a e associa ed o. Fo example, an in ege ield alue
ha con ains he HR alues in bpm is associa ed wi h he ield key "Hea - a e in BPM". In a
moni o ing sys em, se e al use s can ansmi he same ype o da a a he same ime. Tag keys
and ag alues a e s ings and eco d me ada a. In he example, a ag key could be "Use name"
and, na u ally, a ag alues could be "John Doe". Finally, he ields, ags and ime compose a
measu emen .
Tags a e op ional in he da a s uc u e, al hough he use o ags is ad isable because ags a e
indexed, unlike ields. The e o e, que y ags a e as e , making ags ideal o s o ing commonly-
que ied me ada a [71].
In his disse a ion, we moni o he use ’s HR and SpO2 alues and he wea able’s ba e y
pe cen age while di e en ia ing he use . To achie e his equi emen s, we ha e an In luxDB in-
s ance named "Wea ableDB" which has a measu emen called "measu ed_da a" wi h h ee ield
keys: "hea _ a e", "oxygen_le el", "ba e y
_pe cen age", o s o e o da a o HR alues in BPM, SpO2 alues and ba e y pe cen age, e-
spec i ely; and wo ag keys: "wea able_id" s o e he wea able iden i ie (ID) co esponding o he

36 Componen s o he IoT Moni o ing Sys em
da a ansmi ed ( he e is one ID pe wea able) and "wea able_use name" o s o e he wea able’s
use name. Table 3.4 p esen s a isually ep esen a ion o how he da a is s o ed in he da abase.
Table 3.4: In luxDB’s ins ance "Wea ableDB" o wea able da a (illus a i e alues shown)
measu ed_da a
ime hea
_ a e
oxygen
_le el
ba e y
_pe cen age
wea able
_id
wea able
_use name
19:04:32.456 65 95 97 1 John Doe
19:04:32.567 70 96 60 2 Jane Doe
... ... ... ... ... ...
Fu he mo e, we also s o e he log in o ma ion o he moni o ing applica ion and GUI. These
in o ma ion is connec ed o GUI bu ons. The e o e, we ha e an In luxDB ins ance named "GuiLogDB"
ha comp ehends a measu emen called "moni o ing_applica ion_gui_log" wi h one ield key "op-
e a ion" o s o e in o ma ion ela ed o he p essed bu ons, and wo ag keys: "bu on" and "page"
o indica e he bu on and he GUI page i belongs, espec i ely. The "ope a ion" ield key can
in o m ha he sys em s a ed when he "S a " bu on was p essed in he "S a Page" o which
wea able (wi h use name and ID) connec ed o he sys em, o example. Table 3.5 illus a es he
ins ance o s o e moni o ing and GUI log in o ma ion.
Table 3.5: In luxDB’s ins ance "GuiLogDB" o moni o ing applica ion and GUI log in o ma ion
moni o ing_applica ion_gui_log
ime ope a ion bu on page
19:04:33.456 S a Sys em S a S a Page
19:04:35.567 Added wea able wi h use name John Doe
and ID 1 Add Wea able Main Page
... ... ... ...
3.5 Ch onog a
Ch onog aph is he isualisa ion ool o In luxDB da a. I s simple in e ace, embedded li-
b a ies and dashboa d empla es allow he use s o see and analyse da a in eal- ime wi hou need-
ing any knowledge abou In luxDB, which makes i a clea choice o he sys em.
The dashboa ds a e he cen epieces in Ch onog a , which a e composed o cells. A cell is a
cus omizable componen wi h di e en ypes o g aphics, om a line-plo g aphics o his og ams,
allowing he use o choose line colou , legend and no es, among o he s.
To ex ac da a and isualise om he In luxDB, he use c ea es a que y. Ch onog a has an
easy- o-use in e ace o que y c ea ion whe e he use only has o selec an In luxDB ins ance,
measu emen s, ags and ields keys o he desi ed da a. We conside his o be a key ea u e as he
use does no need o know he In luxQL language.
3.6 Summa y 37
Figu e 3.7: Real- ime da a isualisa ion o he pa ien "John Doe"
3.6 Summa y
In his chap e , we p esen ed he sys em’s a chi ec u e wi h oneM2M en i ies and he compo-
nen s ha in eg a e he p oposed IoT moni o ing sys em. Mo eo e , we also p esen ed an o e iew
o each componen , namely a desc ip ion and i s unc ion. This sys em has i s cen al piece in he
OM2M b oke ha ensu es de ice managemen and da a low be ween de ices. A wea able de-
ice, comp ising a LiPo ba e y, an ESP32 and a MAX30102, is used o acqui ing he use ’s
physiological pa ame e s and he wea able’s ba e y pe cen age. On he sys em’s uppe -le el, we
p opose a moni o ing applica ion wi h a GUI o gi e he use he abili y o con ol he sys em wi h
eal- ime in o ma ion display. The wea able da a is s o ed in he ime-se ies da abase In luxDB
and analysed ia Ch onog a .
38 Componen s o he IoT Moni o ing Sys em
Chap e 4
Implemen a ion and Ope a ion o he
IoT Moni o ing Sys em
This chap e desc ibes he sys em’s implemen a ion and ope a ion. Fi s , we gi e an insigh on
he connec ion be ween he MAX30102 and he ESP32 modules in Sec ion 4.1.1. Sec ion 4.1.2
desc ibes he LiPo ba e y as a powe supply. In he Sec ion 4.1.3, we discuss he M2M com-
munica ions be ween bo h he ADN-AE (wea able), he IN-CSE and he IN-AE (moni o ing ap-
plica ion). We conclude he chap e by desc ibing he sys em’s ope a ion wi h one and mul iple
wea ables in Sec ion 4.2. Fo his, we assume a eme gency wa d scena io whe e he pa ien is
he use ha wea s he wea able and he medical pe sonnel is en i y ha con ols he sys em and
analyses da a.
4.1 Implemen a ion and Connec ing Componen s
4.1.1 P ocess Da a om he MAX30102 Senso
The MAX30102 senso has he pu pose o acqui ing HR and SpO2da a om he use . The
da a is collec ed om he senso and is sen o he ESP32 ia I2C. Figu e 4.1 shows he schema ic
o he connec ions be ween he MAX30102 and ESP32.
ESP32
3.3V GPIO26
GND GPIO25
MAX30102
3.3V SDA
GND SCL
Figu e 4.1: Schema ic o he connec ions be ween he MAX30102 and ESP32
39
46 Implemen a ion and Ope a ion o he IoT Moni o ing Sys em
4.2 Sys em Ope a ion
4.2.1 Se up S age
In his sec ion, we desc ibe he sys em ope a ing wi h a single wea able connec ing and ans-
mi ing da a o he moni o ing applica ion, al hough he sys em can handle mul iple wea able
de ices a he same ime.
Fi s , he medical pe sonnel has o s a he moni o ing applica ion and, consequen ly, he GUI
be o e u ning on any wea able. This is a sys em equi emen . A e ini ialising he applica ion,
he "S a Page" o he GUI (Figu e 3.5) appea s. Now, he medical pe sonnel has o p ess he
"START" bu on o allow he wea able o connec o he sys em. The p essing o he bu on igge s
mul iple ac ions, as illus a ed in Figu e 4.7:
• Regis e s, in he IN-CSE, he en i ies o he moni o ing applica ion discussed in Sec-
ion 4.1.3.3;
• Ini ia es communica ion, h ough HTTP, wi h In luxDB;
• Regis e s in he da abase ins ance "GuiLogDB" he s a o he sys em;
• Opens he GUI’s "Main Page".
ADN-AE
Wea able Moni o ing Applica ion wi h GUI
IN-AEIN-CSE
E he ne InfluxDB
AP
WiFi E he ne
"Moni o App",
"Numbe _o _Wea ables",
"Subsc ibe En i y",
"SubNumbe O Wea ables",
"SubCon aine Ba e y",
"SubCon aine H ",
"SubCon aine SpO2"
Regis e en i ies
S a
communica ion
wi h "GuiLogDB" and
"Wea ableDB"
ins ances
W i e in "GuiLogDB"
Sys em s a ed
"START"
bu on
Close "S a
Page", Open "Main
Page"
Figu e 4.7: Sequence diag am o he ac ions pe o med by he moni o ing applica ion a e p ess-
ing he "START" bu on

4.2 Sys em Ope a ion 47
Only now he wea able can be ini ia ed. A e i s ini ialisa ion, i c ea es he co esponding
en i ies e e ed in he Sec ion 4.1.3.3. The wea able c ea es a con en ins ance in he "Num-
be _o _Wea ables" wi h he wea able’s use name and IP, and hen wai s o a "START" signal
om he moni o ing applica ion o s a ansmi ing, which is a con en ins ance in he "Ac ua-
ion" con aine . A e he moni o ing applica ion ecei es he con en ins ance published in he
"Numbe _o _Wea ables", he applica ion c ea es a wea able objec wi h he wea able’s use name
and IP as well as an ID and o he s a us a iables. Al hough he wea able IP is al eady an unique
iden i ie , mos medical pe sonnel don’ ha e knowledge abou IP add esses, hus c ea ing an ID
numbe as i is mo e isually appealing. In he combina ional box below he "Add Wea able"
bu on, a new op ion appea s wi h he wea able’s ID and use name, as shown in Figu e 4.8.
Figu e 4.8: GUI’s "Main Page" wi h he wea able wai ing o be added o he sys em
A his momen , he medical pe sonnel can decide o add he wea able o he moni o ing he
sys em o no . I hey decide no o add he wea able, hey ha e he op ion o add i a a la e ime
h ough he in e ace. On he o he hand, o add he wea able o he sys em, he medical pe sonnel
has o selec he wea able in he combina ional box and p ess he "Add Wea able" bu on. This
ac ion sends a "START" signal o he wea able, which enables i o s a publishing da a, and
adds a line in he able "T ansmi ing Wea ables" wi h he wea able’s ID, use name and ba e y
pe cen age (Figu e 4.9). This las alue is upda ed whene e he wea able publishes a new con en
ins ance wi h a new ba e y pe cen age alue. Addi ionally, a new da a poin wi h he wea able’s
in o ma ion, namely he ID, IP and use name, and he bu on p essed is inse ed in he da abase
ins ance "GUILogDB".
The wea able is now publishing da a o he espec i e con aine s and, consequen ly, he mon-
i o ing applica ion is ecei ing he da a. A e ecei ing a con en ins ance o any da a, he moni-
o ing applica ion inse s a da a poin in he da abase ins ance "Wea ablesDB" wi h he new da a
alue. Figu e 4.10 illus a es he ac ions pe o med be ween he momen s whe e he wea able is
ini ialised and ansmi s da a.
48 Implemen a ion and Ope a ion o he IoT Moni o ing Sys em
Figu e 4.9: GUI’s "Main Page" wi h he wea able ansmi ing da a
4.2.2 De ice & Da a Managemen Du ing Ope a ion
The medical pe sonnel has wo op ions ega ding he wea able s a us: pause/ esume he wea -
able o dele e i om he sys em. Fi s , we ocus on he pause/ esume wea able.
A e p essing he "Add Wea able" bu on, a new op ion appea s in he combina ional box
on he igh o he "Pause Wea able" bu on. I he medical pe sonnel selec s he wea able and
p esses bu on, he moni o ing applica ion sends a "STOP" signal, i.e, a con en ins ance in he
"Ac ua ion" con aine , o in o m he wea able o s op publishing da a. Now he wea able is paused,
he e o e he moni o ing applica ion inse s a new line in he "Paused Wea ables" able wi h he
wea able’s in o ma ion and dele es he co esponding line in he "T ansmi ing Wea ables" able
(Figu e 4.11). Simila ly o he p e ious bu ons, a new da a poin is s o ed in he "GUILogDB".
When he wea able is paused, he medical pe sonnel can esume i s p e ious s a e. To do his, he
medical pe sonnel has o selec he wea able in he combina ional box a he igh o he "Resume
Bu on" and, when selec ed, p ess he bu on. The moni o ing applica ion sends a new "START"
signal o he wea able, dele es he espec i e line om he able "Paused Wea ables" and adds ha
line o he "T ansmi ing Wea ables" able, as shown in Figu e 4.9, and w i es a new da a poin in
he "GuiLogDB" ins ance ha he espec i e wea able has esumed ac i i y.
Figu e 4.12 p esen s he ac ions pe o med o pausing and esuming wea able ac i i y.
A e adding he wea able o he sys em, he medical pe sonnel can dele e he wea able om
he sys em, e en i he wea able is paused. Analogous he o he ac ions, he medical pe sonnel
has o selec he desi ed wea able in he combina ional box below he "Dele e Wea able" bu on
and p ess he bu on. A e he bu on is p essed, he moni o ing applica ion sends a new "STOP"
signal and dele es all he en i ies in he IN-CSE ela ed o he wea able as well as dele es he line
om one o he GUI ables, depending he wea able’s s a us. Figu e 4.13 shows he ac ions a e
p essing "Dele e Wea able".
4.2 Sys em Ope a ion 49
ADN-AE
Wea able Moni o ing Applica ion wi h GUI
IN-AEIN-CSE
E he ne
Publishes con en ins ance
InfluxDB
AP
WiFi E he ne
P ocesses
ecei ed con en
ins ance
Regis e en i ies
"Wea able_IP",
"Wea able_IP_Moni o ",
"Hea _Ra e",
"Oxygen_Le el",
"Ba e y_Pe cen age",
"Ac ua ion",
"Ac ua ion_Subsc ibe "
on he con aine
"Numbe _o _Wea ables",
wi h wea able use name
and IP
Fo wa ds he
con en ins ance
Adds op ion in
combina ional box
below "Add Wea able"
bu on
"Add Wea able"
bu on p essed
Sends "START" signal
which is a con en
ins ance associa ed o
he "Ac ua ion"
con aine
Fo wa ds he "START" signal
Adds line o he "T ansmi ing
Wea ables" able, c ea es a
wea able objec and add op ions in
he comina ional boxes below he
"Dele e Wea able" and a he igh
o he "Pause Wea able" bu on
W i e in "GuiLogDB"
Wea able connec ed o
he sys em
Publishes con en ins ance (da a)
on he espec i e
con aine Fo wa ds he
con en ins ance
P ocesses
ecei ed con en
ins ance
W i e in "Wea ablesDB"
he espec i e
subsc ibed da a
Figu e 4.10: Sequence diag am o add a wea able o he sys em
Las ly, he medical pe sonnel can es a he sys em by clicking he "RESTART" bu on a any
ime. The moni o ing applica ion dele es he all he en i ies egis e ed in he IN-CSE and c ea es
again he en i ies e e ed o he moni o ing applica ion discussed in he Sec ion 4.1.3.3
4.2.3 Da a Visualisa ion
The da a published om he wea able and subsc ibed by he moni o ing applica ion a e s o ed
in he da abase ins ance "Wea ablesDB" associa ed wi h he wea able’s use name and ID. The da a
s o ed can be isualised by he medical pe sonnel by p essing he bu on "Ch onog a ".
50 Implemen a ion and Ope a ion o he IoT Moni o ing Sys em
Figu e 4.11: GUI’s "Main Page" wi h he paused wea able
A e p essing he bu on, a b owse page opens up wi h a page o c ea e a dashboa d o a use .
The medical pe sonnel needs o clone he empla e dashboa d, wi h he name "Wea able - Pa ien ",
o each pa ien . By clicking in he c ea ed dashboa d, he medical pe sonnel is edi ec ed o a new
page wi h wo emp y cells wi h he name "Pa ien - Hea -Ra e (bea s pe minu e)" and "Pa ien -
Blood’s Oxygen Le el (Pe cen age)", as shown in Figu e 4.14. In his page, he medical pe sonnel
can choose he da a e esh a e among o he unc ionali ies.
A ype o da a is associa ed o each cell. The e o e, by edi ing he cell, he medical pe sonnel
can now associa e he da a om he da abase and c ea e g aphics. I is he cell con igu e page
ha a g aphic wi h a ype o da a is c ea ed. Fo example, in Figu e 4.15 he cell p esen s he HR
da a om he wea able wi h he use name "John Doe". In he same page, he da a g aphic is ully
cus omizable on he banne "Visualiza ion" (Figu e 4.16).
Figu e 4.17 shows he dashboa d eal- ime da a o he pa ien "John Doe".
4.2.4 Sys em wi h mul iple wea ables
As s essed ea lie , he sys em p oposed can ha e mul iple wea ables connec ed and ansmi -
ing a he same ime. The e o e, he sys em has unc ionali y o add all he wea ables a he same
ime, which is embedded in he "Add All Wea ables" bu on in he "Main Page". The p ocess o
add all he wea ables o he sys em is he same p esen ed in Figu e 4.10 epea ed he numbe o
ac i e wea ables. Howe e , he medical pe sonnel can add a wea able indi idually.
Addi ionally, he medical pe sonnel can dele e all sys em’s wea ables a he same ime by
clicking he "Dele e All Wea ables" in he "Main Page". Analogous o adding all wea ables a he
same ime, he p ocess o dele e all wea ables is he p ocess p esen ed in Figu e 4.13 epea ed he
numbe o ac i e wea ables.
4.3 Summa y 51
ADN-AE
Wea able Moni o ing Applica ion wi h GUI
IN-AEIN-CSE
E he ne
S ops
publishing
da a
InfluxDB
AP
WiFi E he ne
Sends "STOP" signal
"Pause
Wea able"
bu on
W i e in "GuiLogDB"
Wea able paused
Fo wa ds he "STOP" signal
Adds line o he "Paused
Wea ables" able and adds an
op ion in he comina ional box a
he igh o he "Resume Wea able"
bu on
"Resume
Wea able"
bu on
Sends "START" signal
Fo wa ds he "START" signal Adds line o he "T ansmi ing
Wea ables" able and adds an
op ion in he comina ional box a
he igh o he "Pause Wea able"
bu on
W i e in "GuiLogDB"
Wea able esumed
ac i i y
Publishes con en ins ance (da a)
on he espec i e
con aine Fo wa ds he
con en ins ance
P ocesses
ecei ed con en
ins ance
W i e in "Wea ablesDB"
he espec i e
subsc ibed da a
Figu e 4.12: Sequence diag am o pause and esume a wea able
4.3 Summa y
In his chap e , we p esen ed he mos e icien con igu a ion o he MAX30102, ene gy wise,
based on he s udy in [72] as well as he adap a ions needed o his speci ic. We also discussed
he he powe schema ic o a LiPo ba e y powe ed de ice as well as he schema ic and o mulas
o calcula e ba e y pe cen age. The a chi ec u e includes a se o en i ies and con aine s egis e ed
o he IN-CSE needed o he sys em ope a ion. Las ly, we discussed he applica ion o ou sys em
o an eme gency wa d scena io wi h only one wea able i s and hen wi h mul iple wea ables.

52 Implemen a ion and Ope a ion o he IoT Moni o ing Sys em
ADN-AE
Wea able Moni o ing Applica ion wi h GUI
IN-AEIN-CSE
E he ne
S ops
publishing
da a
InfluxDB
AP
WiFi E he ne
Dele es all ADN-AE en i ies
"Dele e"
bu on
W i e in "GuiLogDB"
Wea able dele ed
Fo wa ds he "STOP" signal
Sends "STOP" signal
Dele es "Wea able_IP"
and i s associa ed
con aine s, and,
"Wea able_IP_Moni o ",
Dele es line om he
GUI able (depending
on he p ei ous
wea able s a us)
Figu e 4.13: Sequence diag am o dele e a wea able om he sys em
Figu e 4.14: Ch onog a ’s pa ien dashboa d
4.3 Summa y 53
Figu e 4.15: Dashboa d cell’s a ea o submi a que y o In luxDB
Figu e 4.16: Dashboa d cell’s isualiza ion a ea
54 Implemen a ion and Ope a ion o he IoT Moni o ing Sys em
Figu e 4.17: Real- ime da a isualiza ion o he pa ien "John Doe"
Chap e 5
Pe o mance Resul s
The use o M2M middlewa es as he oneM2M a e majo s eps o wa d in he de elopmen
o in de eloping M2M and IoT applica ion and p omo ing in e ope abili y and s anda disa ion.
Howe e , his b ings addi ional o e head and delay on he communica ions be ween he de ices.
The addi ional amoun o in o ma ion ha has o be added in each ansmission and, consequen ly,
o he addi ional ime ha each ansmission needs o be comple ed e lec s he p oblem a hand.
The e o e, in he chap e we e alua e he ESP32 in his scena io wi h E2E la ency and PDR o
each p o ocol (CoAP, HTTP and MQTT) and ESP32’s powe mode.
5.1 Se up and Me hodology
We conduc ed he pe o mance expe imen s o he ESP32 module in an indoo en i onmen .
The IN-CSE and he MQTT se e we e ins alled in a dedica ed machine wi h Ubun u 18.04LTS
OS and an In el® Co e™i5-3337U CPU @ 1.80GHz quadco e p ocesso and 4GB o RAM. The
IN-AE (subsc ibe ), ins alled in a compu e wi h he same OS as he se e bu wi h an In el®
Co e™i7-7700HQ CPU @ 2.80GHz oc aco e p ocesso and 16GB o RAM, was connec ed o
he se e machine wi h a 100Mb/s E he ne connec ion. The ADN-AE (ESP32 module) was
connec ed an in as uc u ed local WiFi ne wo k wi h a TP-Link TL-WR940N mul i-mode ou e
as an AP con igu ed o ansmi a Beacon e e y 100ms and a DTIM message e e y 3 Beacons.
Las ly, he AP was connec ed o he IN-CSE machine wi h a 100Mb/s E he ne connec ion.
The ADN-AE and he IN-AE a e no ins alled in he same machine, he e o e we used a
Ne wo k Time P o ocol (NTP) se e , ins alled on he IN-CSE machine, o synch onise he AEs
clocks. Bo h applica ions e-synch onise wi h he se e e e y 10 minu es. This e-sycnh onize
ime in e al alue is he minimum alue allowed by he ESP-IDF amewo k.
We conduc ed he expe imen s ega ding he WiFi communica ion channel quali y. A i s , he
ADN-AE publishes da a e y close o he AP wi h a Recei ed Signal S eng h Indica ion (RSSI)
alue o -30, which we denomina e as good signal s eng h channel expe imen . Fo he bad signal
s eng h channel expe imen , he ADN-AE published he da a u he away om he AP wi h a
RSSI alue o -85. Fo each channel quali y expe imen , he ADN-AE publishes da a wi h di e en
55
62 Pe o mance Resul s
ESP32 Powe Modes
Ac i e MinModem MaxModem MinModemALMaxModemAL
Numbe o Non-deli e ed Packe s
0
5
10
15
20
25
30
35
40
45
50
ESP32 Powe Modes
Ac i e MinModem MaxModem MinModemALMaxModemAL
Numbe o Non-deli e ed Packe s
0
5
10
15
20
25
30
35
40
45
50
Figu e 5.9: Packe s Non-deli e ed o he bad signal s eng h channel wi h MQTT QoS0 wi h 85B
(le ) and 850B ( igh ) o message payload o each powe mode
Table 5.9: Packe s Non-deli e ed o he bad signal s eng h channel expe imen wi h MQTT
QoS0
Powe Mode 85B payload (%) 850B payload (%)
Ac i e 90 90
MinModem 90 90
MaxModem 79 80
MinModemAL 70 70
MaxModemAL 70 70
A e age 79.8 80
ESP32 Powe Modes
Ac i e MinModem MaxModem MinModemALMaxModemAL
End- o-End La ency (ms)
20
30
40
50
60
70
80
90
ESP32 Powe Modes
Ac i e MinModem MaxModem MinModemALMaxModemAL
End- o-End La ency (ms)
20
30
40
50
60
70
80
90
Figu e 5.10: E2E la ency esul s o he good signal s eng h channel wi h MQTT QoS1 wi h 85B
(le ) and 850B ( igh ) o message payload o each powe mode
Rega ding he bad signal s eng h channel expe imen , Figu e 5.11 p esen s he E2E la ency
esul s o 85B and 850B o message payloads o each powe mode and Table 5.11 indica es he
mean alues o he p e ious esul s.
Fo he PDR, Figu e 5.12 p esen s he E2E la ency esul s o 85B and 850B o message
payloads o each powe mode and Table 5.12 indica es he mean alues o he p e ious esul s.

5.2 End- o-end La ency Expe imen s 63
Table 5.10: Mean alues o he good signal s eng h channel expe imen wi h MQTT QoS1
Powe Mode 85B payload (ms) 850B payload (ms)
Ac i e 24.2 26.1
MinModem 25.6 28.1
MaxModem 25.2 27.1
MinModemAL 26.0 26.7
MaxModemAL 26.9 26.3
A e age 25.6 26.7
ESP32 Powe Modes
Ac i e MinModem MaxModem MinModemALMaxModemAL
End- o-End La ency (ms)
20
30
40
50
60
70
80
90
ESP32 Powe Modes
Ac i e MinModem MaxModem MinModemALMaxModemAL
End- o-End La ency (ms)
20
30
40
50
60
70
80
90
Figu e 5.11: E2E la ency esul s o he bad signal s eng h channel wi h MQTT QoS1 wi h 85B
(le ) and 850B ( igh ) o message payload o each powe mode
Table 5.11: Mean alues o he bad signal s eng h channel expe imen wi h MQTT QoS1
Powe Mode 85B payload (ms) 850B payload (ms)
Ac i e 30.1 31.8
MinModem 32.2 33.6
MaxModem 35.4 36.0
MinModemAL 29.4 31.1
MaxModemAL 34.1 36.8
A e age 32.2 33.9
Table 5.12: Packe s Non-deli e ed o he bad signal s eng h channel expe imen wi h MQTT
QoS1
Powe Mode 85B payload (%) 850B payload (%)
Ac i e 90 90
MinModem 90 90
MaxModem 80 80
MinModemAL 70 70
MaxModemAL 70 70
A e age 80 80
64 Pe o mance Resul s
ESP32 Powe Modes
Ac i e MinModem MaxModem MinModemALMaxModemAL
Numbe o Non-deli e ed Packe s
0
5
10
15
20
25
30
35
40
45
50
ESP32 Powe Modes
Ac i e MinModem MaxModem MinModemALMaxModemAL
Numbe o Non-deli e ed Packe s
0
5
10
15
20
25
30
35
40
45
50
Figu e 5.12: Packe s Non-deli e ed o he bad signal s eng h channel wi h MQTT QoS1 wi h
85B (le ) and 850B ( igh ) o message payload o each powe mode
5.2.3.3 MQTT QoS2
Figu e 5.13 p esen s he E2E la ency esul s o he good signal s eng h channel o 85B and
850B o message payloads o each powe mode and Table 5.13 indica es he mean alues o he
p e ious esul s.
ESP32 Powe Modes
Ac i e MinModem MaxModem MinModemALMaxModemAL
End- o-End La ency (ms)
20
30
40
50
60
70
80
90
ESP32 Powe Modes
Ac i e MinModem MaxModem MinModemALMaxModemAL
End- o-End La ency (ms)
20
30
40
50
60
70
80
90
Figu e 5.13: E2E la ency esul s o he good signal s eng h channel wi h MQTT QoS2 wi h 85B
(le ) and 850B ( igh ) o message payload o each powe mode
Table 5.13: Mean alues o he good signal s eng h channel expe imen wi h MQTT QoS2
Powe Mode 85B payload (ms) 850B payload (ms)
Ac i e 31.4 33.4
MinModem 33.2 35.7
MaxModem 33.0 34.6
MinModemAL 32.4 37.4
MaxModemAL 33.8 39.6
A e age 32.8 36.1
5.2 End- o-end La ency Expe imen s 65
Rega ding he bad signal s eng h channel expe imen , Figu e 5.14 p esen s he E2E la ency
esul s o 85B and 850B o message payloads o each powe mode and Table 5.14 indica es he
mean alues o he p e ious esul s.
ESP32 Powe Modes
Ac i e MinModem MaxModem MinModemALMaxModemAL
End- o-End La ency (ms)
20
30
40
50
60
70
80
90
ESP32 Powe Modes
Ac i e MinModem MaxModem MinModemALMaxModemAL
End- o-End La ency (ms)
20
30
40
50
60
70
80
90
Figu e 5.14: E2E la ency esul s o he bad signal s eng h channel wi h MQTT QoS2 wi h 85B
(le ) and 850B ( igh ) o message payload o each powe mode
Table 5.14: Mean alues o he bad signal s eng h channel expe imen wi h MQTT QoS2
Powe Mode 85B payload (ms) 850B payload (ms)
Ac i e 43.8 56.8
MinModem 44.0 43.8
MaxModem 41.4 66.4
MinModemAL 49.2 55.4
MaxModemAL 45.9 72.7
A e age 44.9 59.0
Fo he PDR, Figu e 5.15 p esen s he E2E la ency esul s o 85B and 850B o message
payloads o each powe mode and Table 5.15 indica es he mean alues o he p e ious esul s.
ESP32 Powe Modes
Ac i e MinModem MaxModem MinModemALMaxModemAL
Numbe o Non-deli e ed Packe s
0
5
10
15
20
25
30
35
40
45
50
ESP32 Powe Modes
Ac i e MinModem MaxModem MinModemALMaxModemAL
Numbe o Non-deli e ed Packe s
0
5
10
15
20
25
30
35
40
45
50
Figu e 5.15: Packe s Non-deli e ed o he bad signal s eng h channel wi h MQTT QoS2 wi h
85B (le ) and 850B ( igh ) o message payload o each powe mode
66 Pe o mance Resul s
Table 5.15: Packe s Non-deli e ed o he bad signal s eng h channel expe imen wi h MQTT
QoS2
Powe Mode 85B payload (%) 850B payload (%)
Ac i e 90 90
MinModem 90 90
MaxModem 80 80
MinModemAL 70 70
MaxModemAL 70 70
A e age 80 80
5.2.4 P o ocols Compa ison
Figu e 5.16 p o ides an o e iew he impac o all he p o ocols and ESP32 module’s powe
modes on E2E la ency wi h 85B o payload o he good signal s eng h channel expe imen s.
Addi ionally, Figu e 5.17 p esen s he E2E la ency esul s wi h 850B o payload o he good signal
s eng h channel expe imen . As s essed ea lie , he e a e no packe s los o his expe imen
ESP32 Powe Modes
1 2 345 6 7 8 9 10111213141516171819202122232425
End- o-End La ency (ms)
20
30
40
50
60
70
80
90
Ac i e MinModem MaxModem MinModemAL MaxModemAL
Figu e 5.16: E2E la ency esul s wi h 85B o payload o he good signal s eng h channel expe i-
men
Rega ding he bad signal s eng h channel expe imen , Figu es 5.18 and 5.19 p esen he E2E
la ency esul s wi h 85B and 850B o payload, espec i ely.
Fo he PDR, Figu e 5.20 and Figu e 5.21 show he packe s non-deli e ed o messages wi h
85B and 850B o he "bad" channel, espec i ely.
These g aphics a e composed by blocks o i e measu emen s. The i s measu emen s, 1-5,
co espond o he Ac i e mode. Measu emen s 6-10 co espond o Minimum Modem mode and
5.2 End- o-end La ency Expe imen s 67
ESP32 Powe Modes
1 2 345 6 7 8 9 10111213141516171819202122232425
End- o-End La ency (ms)
20
30
40
50
60
70
80
90
Ac i e MinModem MaxModem MinModemAL MaxModemAL
Figu e 5.17: E2E la ency esul s wi h 850B o payload o he good signal s eng h channel expe -
imen
ESP32 Powe Modes
1 2 345 6 7 8 9 10111213141516171819202122232425
End- o-End La ency (ms)
20
30
40
50
60
70
80
90
Ac i e MinModem MaxModem MinModemAL MaxModemAL
Figu e 5.18: E2E la ency esul s wi h 85B o payload o he bad signal s eng h channel expe i-
men
measu emen s 11-15 co espond o Maximum Modem. The las wo blocks a e associa ed he
Minimum Modem and Maximum Modem modes wi h au oma ic Ligh sleep, espec i ely. Inside
he block, he posi ions a e o ganised by p o ocols:

68 Pe o mance Resul s
ESP32 Powe Modes
1 2 345 6 7 8 9 10111213141516171819202122232425
End- o-End La ency (ms)
20
30
40
50
60
70
80
90
Ac i e MinModem MaxModem MinModemAL MaxModemAL
Figu e 5.19: E2E la ency esul s wi h 850B o payload o he bad signal s eng h channel expe i-
men
ESP32 Powe Modes
0 5 10 15 20 25
Numbe o Non-deli e ed Packe s
0
5
10
15
20
25
30
35
40
45
50 Ac i e MinModem MaxModem MinModemAL MaxModemAL
Figu e 5.20: Packe s non-deli e ed wi h 85B o payload o he bad signal s eng h channel ex-
pe imen
• Posi ion 1: CoAP Non-con i mable;
• Posi ion 2: HTTP;
5.2 End- o-end La ency Expe imen s 69
ESP32 Powe Modes
0 5 10 15 20 25
Numbe o Non-deli e ed Packe s
0
5
10
15
20
25
30
35
40
45
50
Ac i e MinModem MaxModem MinModemAL MaxModemAL
Figu e 5.21: Packe s non-deli e ed wi h 850B o payload o he bad signal s eng h channel
expe imen
• Posi ion 3: MQTT QoS0;
• Posi ion 4: MQTT QoS1;
• Posi ion 5: MQTT QoS2.
As expec ed, he E2E la ency esul s o he bad signal s eng h channel expe imen a e g ea e
han he esul s o he good signal s eng h channel as i has an a e age inc ease o 30.24% o
85B and 38.20% o 850B.
The di e en message payload also has an impac on he E2E la ency esul s as he esul s o
he 850B o payload inc ease when compa ed o he 85B o payload esul s. Fo he good signal
s eng h channel expe imen , he e is an inc ease o 7.42% o CoAP Non-con i mable, 9.18%
o HTTP, 8.56% o MQTT QoS0, 5.00% o MQTT QoS1 and 10.25% o MQTT QoS2 o
850B o payload. Thus, o he good signal s eng h channel, he e’s is an a e age inc ease o
8.08%. Rega ding he bad signal s eng h channel he e is also an inc ease on E2E la ency when
compa ing he esul s 850B o 85B o payload o all p o ocols. The a e age la ency inc eases
8.82% o CoAP Non-con i mable, 12.05% o HTTP, 9.39% o MQTT QoS0, 5.03% o MQTT
QoS1 and 31.58% o MQTT QoS2. Mo eo e , he e is an a e age inc ease o 38.14% o 850B
when compa ing he wo channels expe imen s.
Fo he good signal s eng h channel, he E2E la ency expe ienced is wi hin 20-28ms o mes-
sages wi h 85B o payload o all p o cols excep MQTT QoS2, which expe ience E2E la ency
be ween 29-35ms.
70 Pe o mance Resul s
The p o ocols ha use TCP as i s anspo laye p o ocol, i.e. MQTT and HTTP, shown an
inc eased la ency ela i ely o CoAP uses he UDP, al hough his di e ences a e negligible o he
good signal s eng h channel expe imen , excep o MQTT QoS2 (Table 5.13).
Rega ding he ESP32 module’s powe modes, a g ea e la ency is expe ienced when compa ing
mo e ene gy-e icien powe modes wi h he less ene gy-e icien powe modes, al hough i is no
signi ican and in some cases he la ency is bigge in less ene gy-e icien powe modes. Fo
example, he E2E la ency dec eases 26.26% o Maximum Modem mode wi h Au oma ic Ligh
Sleep when compa ed o Ac i e mode o CoAP Non-con i mable wi h 85B payload o he bad
signal s eng h channel expe imen .
Fo he good signal s eng h channel, he PDR is 100% al hough ha is no he case o he bad
signal s eng h channel, as expec ed. We conclude ha he alue is highe in less ene gy-e icien
powe modes when compa ing wi h mo e ene gy-e icien powe modes o he bad signal s eng h
channel, ega dless o message payload and ALP. As shown in Figu e 5.20 and Figu e 5.21, he
di e ences in he PDR be ween messages wi h 85B and 850B and p o ocols a e negligible. When
compa ing he ESP32 powe modes, we conclude ha he e is dec ease o 10% o he Maximum
Modem sleep and 20% o bo h Minimum Modem sleep and Maximum Modem sleep wi h au o-
ma ic Ligh -sleep on he PDR when compa ing o he Ac i e-sleep and Minimum Modem sleep.
To conclude, he WiFi channel quali y has a g ea impac on he expe ienced E2E la ency. The
TCP-based p o ocols also expe ience a g ea e la ency when compa ed o CoAP. MQTT QoS2
is he p o ocol ha expe iences a g ea e E2E la ency due o he ac ha exchanges ou mes-
sages o publish one message. Finally, scena ios whe e using mo e ene gy-e icien powe modes
expe ience mo e E2E la ency and less PDR.
5.3 Summa y
In his chap e , we p esen he me hodology and he esul s o sys em’s pe o mance e alua-
ion. The esul s alida e he use o he ESP32 module on applica ions simila o he one p oposed
in his p ojec , by publishing messages wi h 85B and 850B o payload wi h 1 second and 10 sec-
onds pe iod o di e en WiFi quali y channels. The esul s show ha he la ency expe ience when
compa ing he channel quali ies is signi ican , howe e when compa ing he la ency expe ienced
wi h di e en powe modes in he same channel quali y scena io is no signi ican . Finally, he
PDR is highe when he ESP32 is using a less ene gy-e icien powe mode when compa ing o a
mo e ene gy-e icien powe mode.
Chap e 6
Conclusion
IoT echnologies ha e expe ienced a apid g ow h in ecen yea s in hei applicabili y in se -
e al domains, such as he heal hca e. The e o e, se e al s anda ds and p o ocols we e de eloped
speci ically o his new echnology. In oday’s socie y, WiFi is an omnip esen echnology, hus
small embedded sys ems s a suppo ing WiFi echnology. This is a key ea u e due o a oidance
o a GW de ice connec he sys em o he In e ne .
In his wo k, we p oposed and implemen ed an IoT sys em ha en isions o sa is y he e-
qui emen s o emo e heal h moni o ing while using a low-cos low-cos WiFi-enabled de ice. To
gua an ee he in e ope abili y be ween de ices, we used he oneM2M s anda d. Rega ding M2M
communica ions be ween de ices, we implemen ed CoAP, HTTP and MQTT p o ocols.
The sys em p oposed is based on he oneM2M, which allows a publishe -subsc ibe commu-
nica ion model, a g ea model o sensing and emo e moni o ing applica ion such as his. The
sys em p oposed comp ises a wea able based on an Esp essi ESP32 module, a MAX30102 PPG
module and a LiPo ba e y, and a moni o ing applica ion wi h GUI as well as a da abase. In luxDB,
and a da a isualisa ion ool. The ESP32 module is he cen al piece o he wea able because p o-
cesses he da a acqui ed in he MAX30102 module, i.e. HR and SpO2, and calcula es ba e y
pe cen age and publishes o he OM2M b oke , IN-CSE. The moni o ing applica ion con ols he
da a low be ween he main componen s o he sys em, hus communica ing wi h he In luxDB and
subsc ibing da a om he IN-CSE. We also de eloped a GUI o gi e a isually aid o he eal- ime
s a us o he sys em as well as con olling i .
Th ough he GUI, he medical pe sonnel can add a wea able(s) o he sys em which allows
he wea able(s) o s a publishing da a. A any momen , he medical pe sonnel can dele e he
wea able(s) om he sys em as well as pause he wea able. Addi ionally, he GUI o e s a bu on
o open he Ch onog a applica ion which enables he medical pe sonnel o analyse da a s o ed on
he da abase.
Rega ding he sys em’s pe o mance, we conduc ed E2E la ency expe imen s, wi h da a ans-
missions a di e en equencies, using di e en powe modes o e ed by he ESP32 module o
wo WiFi channel quali y expe imen s ega ding signal s eng h. The esul s show ha he E2E
la ency o a bad WiFi channel quali y inc eases 30.24% and 38.20% o messages published wi h
71
78 REFERENCES
[69] Esp essi Sys ems. Wi i powe sa e example, 2020. h ps://gi hub.com/
esp essi /esp-id / ee/ elease/ 3.3/examples/wi i/powe _sa e, Las
accessed on 2020-06-17.
[70] Maxim In eg a ed. High-Sensi i i y Pulse Oxime e and Hea -Ra e Senso o Wea able
Heal h MAX30102. Technical epo , 2015. URL: h ps://www.maximin eg a ed.
com/en/p oduc s/in e ace/senso -in e ace/MAX30102.h ml.
[71] In luxDa a. In luxdb key concep s, 2020. h ps://docs.in luxda a.com/
in luxdb/ 1.8/concep s/key_concep s/, Las accessed on 2020-06-24.
[72] Miguel Ribei o. Wea able senso o con inuous moni o ing o physiological pa ame e s.
Mas e ’s hesis, Facul y o Engenee ing (FEUP), Uni e si y O Po o, 2020.
[73] Maxim In eg a ed. Pulse Oxime e and Hea -Ra e Senso IC o Wea able Heal h. Tech-
nical epo , 2015. URL: h ps://www.maximin eg a ed.com/en/p oduc s/
senso s/MAX30100.h ml.
[74] oneM2M. Mq p o ocol binding, 2018. h p://www.onem2m.o g/images/ iles/
deli e ables/Release2A/TS-0010-MQTT_p o ocol_binding- _2_7_1.
pd , Las accessed on 2020-07-01.
[75] João Mesqui a. Comunicação WiFi pa a moni o ização mó el de sinais isiológicos. Mas e ’s
hesis, Facul y o Engenee ing (FEUP), Uni e si y o Po o, 2018.
[76] Eclipse Founda ion. Mq c clien o posix and windows, 2020. h ps://www.eclipse.
o g/paho/clien s/c/, Las accessed on 2020-07-05.
[77] Eclipse Founda ion. onem2m ja a applica ions, 2017. h ps://wiki.eclipse.o g/
OM2M/one/App, Las accessed on 2020-07-01.