Remote biometrical monitoring system via IoT

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.