[image] [image] Ressource protégée - Inria - Institut national de recherche en sciences et technologies du numérique [Accéder directement au contenu](#)

[image] [image]

* [Documentation](#)

* FR
  Français (FR)

* Anglais (EN)
  Se connecter

* [Portail HAL Inria](#)

* Recherche
  Loading...

## Recherche avancée

Information de documents

Titres

○ Titres

○ Sous-titre

○ Titre de l'ouvrage

○ Titre du volume (Série)

○ Champ de recherche par défaut (multicritères) + texte intégral des PDF

○ Résumé

○ Texte intégral indexé des documents PDF

○ Mots-clés

○ Type de document

○ Sous-type de document

○ Tous les identifiants du document

○ Identifiant HAL du dépôt

○ Langue du document (texte)

○ Pays (Texte)

○ Ville

○ À paraître (true ou false)

Ajouter
<figure><img src="image_1.png" /></figure>

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
## Auteur

### Auteur (multicritères)

○ Auteur (multicritères)

○ Auteur : Nom complet

○ Auteur : Nom de famille

○ Auteur : Prénom

○ Auteur : Complément de nom, deuxième prénom

○ Auteur : Organisme payeur

○ Auteur : IdHal (chaîne de caractères)

○ Auteur : Fonction

○ Auteur : personID (entier)

○ Auteur : Identifiant de l'organisme payeur

○ Auteur : Identifiant de la structure

○ Directeur de thèse

○ Éditeur

○ Éditeur scientifique

○ Éditeur de la série

## Ajouter

### Structure

### Structure (multicritères)

○ Structure (multicritères)

○ Structure : Acronyme

○ Structure : Nom

○ Structure : Code

○ Structure : Pays

○ Structure : Type

○ Structure : État dans le référentiel

○ Structure : Identifiant HAL de la structure

○ Structure/équipe de recherche : Pays

○ Structure/regroupement d'équipes : Pays

○ Structure/laboratoire : Pays

○ Structure/regroupement de laboratoires : Pays

○ Structure/institution : Pays

○ Structure/regroupement d'institutions : Pays

## Ajouter
# A Secure and Efficient Cloud-Connected Body Sensor Network Platform

Myles Keller, Brooks Olney, and Robert Karam

University of South Florida, Tampa FL 33620, USA
{myleskeller, brooksolney, rkaram}@usf.edu

**Abstract.** A Body Sensor Network (BSN) is a system made up of low-power sensor nodes that monitor the wearer's body and surroundings. BSNs have emerged as a prominent technology, largely influenced by the increased health consciousness, widespread availability of wireless-enabled consumer electronics, and growing wireless connectivity infrastructure. In this paper, we present an extensible, cloud-connected BSN platform leveraging lightweight, efficient compression and encryption techniques suitable for edge computing. The platform includes a tunable wavelet-based compression algorithm, suitable for biosignal compression, a lightweight, secure block cipher (SPARX) to encrypt data during transmission, and Amazon Web Services (AWS) connectivity via Message Queuing Telemetry Transport (MQTT). We utilize this platform to evaluate the benefits of compressing sensor data by comparing the delay, power, and energy efficiency on the BSN platform when transmitting encrypted data to the cloud. The tunable compression algorithm efficiently reduces the size of transmitted packets on diverse types of sensor data, with low reconstruction error. When paired with a lightweight block cipher, the combination enables improvements in energy consumption (38%) and energy efficiency (58%) when compared to encryption alone.

**Keywords:** Body sensor networks · Edge computing · Cryptography · Low power · Cloud storage · Data compression

## 1 Introduction

Body Sensor Networks (BSNs) have evolved into a groundbreaking technology in the public health sector [26, 1, 6]. Wearable sensors can provide a convenient, non-invasive option for continuous, real-time sensing of physiological properties such as heart rate, movement, and blood pressure, among others [29]. This information can be useful to healthcare professionals in properly assessing their patients' ailments and care needs and represents a step towards truly personalized healthcare.

BSNs have a considerably easier time connecting to cloud infrastructure now that more products are equipped with wireless access points and most public and private buildings have some form of Wi-Fi connectivity. Moreover, 5G-enabled devices and infrastructure are becoming more pervasive, enabling communication directly between the bio-sensors and the cloud [15].
Autres

Champ de recherche par défaut (multicritères)

○ <u>Champ de recherche par défaut (multicritères)</u>

○

○ <u>Revues (multicritères)</u>

○ <u>Revue : Éditeur</u>

○ <u>Revue : Titre abrégé</u>

○ <u>Revue : Titre</u>

○ <u>Revue : Identifiant interne</u>

○ <u>Revue : Date de début de publication</u>

○ <u>Revue : ISSN électronique</u>

○ <u>Revue : ISSN</u>

○ <u>Revue : Éditeur</u>

○ <u>Revue : Couleur dans SHERPA/RoMEO</u>

○ <u>Revue : État dans le référentiel</u>

○

○ <u>Colloque (multicritères)</u>

○ <u>Colloque : Titre</u>

○ <u>Colloque : Organisateur</u>

○ <u>Colloque : date de début (Année)</u>

○ <u>Colloque : date de fin (Année)</u>

○ <u>Conférence invitée (oui/non)</u>

○

○ <u>Projets ANR (multicritères)</u>

○ <u>Projet ANR : Acronyme</u>

○ <u>Projet ANR : Acronyme du programme</u>

○ <u>Projet ANR : Code décision (référence)</u>

○ <u>Projet ANR : Nom</u>

○ <u>Projet ANR : Identifiant interne</u>

○ <u>Projet ANR : État dans le référentiel</u>

○

○ <u>Projets européens (multicritères)</u>

○ <u>Projet européen : Acronyme</u>

○ <u>Projet européen : Identifiant de l'appel à projet</u>

○ <u>Projet européen : Référence</u>

○ <u>Projet européen : Nom</u>

○ <u>Projet européen : Date de fin</u>

○ <u>Projet européen : Financement</u>

○ <u>Projet européen : Date de début</u>
While this improved networking infrastructure is undoubtedly beneficial in ensuring that BSN telemetry reaches healthcare providers as quickly and reliably as possible, there are a number of potential security and privacy issues associated with widely available internet connectivity for BSNs. The data broadcast to the cloud from a BSN is often comprised of both the wearer's medical telemetry data as well as data relevant to their perceived surroundings. While this can be useful in healthcare, if this data is compromised, it could reveal sensitive personal information about an individual's health activities, location, and habits. To combat these security and privacy risks, encryption can be implemented on the BSN; however, this can be computationally expensive and power hungry. Most embedded devices which are used in BSN platforms are equipped with small form-factor microcontrollers, which require special algorithms and implementations for cryptographic operations due to their limited available energy and program instruction size. Hence, development of lightweight block ciphers [5, 4, 30] and their subsequent evaluations on different Internet of Things (IoT) platforms [7, 19, 8] have been critical in addressing these concerns and enabling many advancements in the areas of IoT and wearable BSNs. Any data pre-processing, such as data compression and encryption, should consume minimal power so as not to intrude on the needs of the embedded network connectivity hardware.

Wi-Fi and 4G connections account for the majority of cloud infrastructure connections and require far more energy than most other wireless communication technologies [17]. Considering that the majority of BSN ecosystems are made up of small, worn or implanted electronics with relatively limited battery capacities, one can appreciate the importance of making all correspondence with the cloud as brief and meaningful as possible. Reducing communication frequency is a realistic strategy for decreasing energy consumption, but it comes at a cost of less frequent updates which is not suitable in all situations, including any instance where real-time decision making is needed, e.g. in a closed-loop treatment system.

In cases where the system is required to communicate in real-time with little to no delay, the system must be transmitting frequently, which consumes a significant amount of power. Therefore, compressing the data before encrypting and delivering it to the cloud may be advantageous. While there are many works which propose different methods of BSN data compression, to the best of our knowledge, there are no other works which present a framework for an extensible BSN while simultaneously evaluating the impact of data compression and encryption on the power consumption of devices in a BSN.

The main contributions of this paper are as follows:

1. We present a customizable BSN platform that integrates AWS connectivity

2. We implement a tunable and efficient compression algorithm suitable for microcontroller implementation to compress signals from the body sensors

3. We integrate a light weight block cipher (SPARX) directly within the BSN to encrypt the user's data prior to transmission

4. We demonstrate the need for local processing by comparing the power consumption of the device with and without data compression and encryption
○ Projet européen : État dans le référentiel

○ Projet européen : Identifiant interne

○

○ Date de production : année

○ Date de mise en ligne : année

○ Date de publication : année

○ Date d'écriture : année

○ Date de modification du dépôt : année

○ Date de dépôt : année

○ Date de publication électronique : année

○

○ Collection HAL (multicritères)

○ Collection HAL : catégorie

○ Collection HAL : Code

○ Collection HAL : Nom

○ Collection HAL : Identifiant interne

○

○ Identifiant interne du contributeur/déposant

○ Nom complet du contributeur/déposant

○

○ Domaines

○ Domaine primaire

○ Domaine racine

○ Sous-domaine niveau 1

○ Sous-domaine niveau 2

○ Sous-domaine niveau 3

○

○ Statut du document

○ Version du document

○ Type de dépôt

○ Type de document

○ ISBN

○ Numéro - référence

○ Identifiant DOI

○

○ Classification

○ Audience

○ Vulgarisation

○ Comité de lecture - texte (oui ou non)

○ Actes de colloque
We found that the compression algorithm not only effectively and efficiently
reduces the packet size for diverse types of sensor data, it also enables us to
implement a lightweight block cipher while consuming considerably less energy
and reducing the overall processing time. The rest of the paper is structured
as follows: in Section 2 we provide a background on BSNs, data compression
and data encryption. In Section 3 we present the methodology of our approach,
including the design of the platform itself, the algorithms used for compression
and encryption, and the experimental setup. In Section 4 we present and discuss
the results of our approach. Finally, we conclude in Section 5 with future work.

## 2 Background

In this section, we start by providing a background on BSNs and how they fit
into standard IoT architectures. Then, we describe several data encryption and
compression techniques designed for use in BSNs.

### 2.1 Body Sensor Networks

A Body Sensor Network (BSN) is a system made up of low-power sensor nodes that monitor the wearer's body and surroundings. Current research on BSN platforms largely focuses on advancements in wireless connectivity [28, 12], evolving network and data security paradigms [22], and development of platform implementations within domains such as the public health sector [21]. For example, Figure 1 presents a diagram of a BSN containing a variety of connected devices. Each device monitors a different physiological phenomena and reports back to a central point. This central point then relays this information through the cloud or local network for a corresponding application for the user and/or medical professional.

BSNs are commonly composed of a variety of devices. This has motivated research efforts towards multi-sensor data fusion enabled systems for merging the functionality of these sensors into one seamless platform [12, 21, 14]. Sensor fusion typically focuses on using multiple different sensors (or the same sensor) at different locations with different amounts of spatial coverage and thus sensor fidelity. High quality sensor fusion can greatly improve the usability of the BSN application. However, fusion approaches introduce a number of processing complexities and may require additional sensor communication – resulting in information and performance losses [12].

The sensors themselves may be non-invasive wearables such as smart watches, or more invasive implantable devices which are designed to monitor internal physiological signals. To be minimally invasive, implantable devices are designed to be as small as possible and, consequently, have small batteries, and must operate very conservatively. This alone is a strong motivation to minimize the computational overhead in these devices to prolong their lifetime [16].

Wireless sensors that compose the BSN are the fundamental building blocks
of the system, with several different layers of data pre-processing and application
○ Référence interne

○ Financement

○ Collaborations

Ajouter

Lancer la recherche
Recherche experte (SolR)

Recherche experte (SolR)

Lancer la recherche
Vers la recherche avancée

• Déposer

Portail INRIA.HAL.SCIENCE
Les publications, logiciels... des scientifiques Inria

• Accueil

• Publications Inria

○ Consulter les derniers dépôts

○ Par équipe de recherche

○ Par auteur

○ Rapports de recherche et techniques

○ Livres blancs

○ Rapports d'activité des équipes

○ Statistiques

• Boite à Outils

○ X2Hal : importer par lot

○ Logiciels : créer le Codemeta.json

○ Créer mon IDHal

○ Créer mon CVHal

○ Haltools : créer ma page de publications

○ Haltools : extraire des données (réservé Inria)

○ Les bonnes pratiques

■ Comment bien s'affilier ?
<figure><img src="image_2.png" /><figcaption>Fig. 1: Example of a Body Sensor Network (BSN) consisting of multiple wired/wireless sensors, surgically implanted or worn on the body, used for physiological monitoring, personalized medical treatment, and/or closed-loop control of integrated subsystems.</figcaption></figure>

design built to support them. As described by Gravina et al. [13], the typical system architecture of a BSN consists of two to four of the following layers:

* *Body* - programmable sensors either wearable by the user or safely implanted

* *Mobile* - smartphones, smartwatches, and tablets which have an interactive graphical interface for monitoring and maintaining the hardware devices

* *Edge* - optional intermediate layer which may subside between the body sensors and mobile applications or other devices

* *Cloud* - optimal for offloading complex computations and data storage. and is also often integrated with the mobile and/or edge layer(s)

The specific platform architecture used by this work is described in detail in Section 3, but broadly, we use body sensors with a user-friendly, browser-based front-end, accessible from an authorized mobile device. This front-end allows the user to monitor sensor data in a real-time, but is optional, as the BSN supports direct-to-cloud upload capabilities.

## 2.2 Data Privacy and Security

In BSN platforms, proper data privacy and security methods must be in place to ensure integrity of the system and privacy of the user. Considering that the devices are monitoring and transmitting sensitive location and physiological information about a user, an attacker may want to gain unauthorized access to this data for their own illicit means. To this end, many different lightweight block ciphers have been proposed that can be used to encrypt sensitive data by general purpose microcontrollers and microprocessors which commonly exist within these hardware platforms [18, 25]. Aside from the encryption algorithms themselves, there have also been several advancements which propose different optimizations to data privacy in BSNs in general [23]. For example, the authors
■ Quelle version puis-je déposer ?

■ Choisir le bon « type de document »

■ Mettre en valeur ses publications

○ Les tutos IES Inria

■ Lier les notices dans HAL

■ Umbrhal Inria pour l'accessibilité

■ Personnaliser son CVHAL

■ Créer et Personnaliser sa collection

• Documentation

○ Aide en ligne HAL

○ Aide en ligne Haltools

○ Aide en ligne X2hal

○ Tutoriels video HAL

○ Documentation API HAL

○ Ajouter des vignettes

○ Identifiant auteur IdHAL et CV

○ Compléter son dossier ORCID avec ses dépôts HAL

○ Inria et la Science Ouverte

X

X

X

Loading...

X

Le document que vous demandez est en access restreint
jusqu'au 2025-01-01 !

Revenir a la notice

Retourner à l'accueil

Contact

•

Ressources
in [24] propose a selective encryption scheme for electrocardiogram data which uses supervised machine learning to determine the most important parts of the signals to encrypt. Doing so can minimize the amount of data that has to be encrypted, and even filter out a great deal of data.

## 2.3 Data Compression

Naturally, because sensors are often configured to operate in real-time, they may generate a large amount of data. This presents two main problems: 1) the device itself must transmit more data and thus consumes more power, and 2) extra storage (e.g. in the cloud) may be required for the accumulated data. In recent years, researchers have investigated different methods of data compression specifically geared toward BSNs and the types of data they sense [10, 11, 3]. In [3] the authors presented a lossless transform-based technique leveraging the Discrete Wavelet Transform (DWT) extended with Lagrange polynomial interpolation. They evaluated their framework on multiple different sensors – temperature, pressure, gyroscope, accelerometer – and demonstrated they could compress the data anywhere from 30% to 92%, depending on the sensor type. Though promising, the authors do not present an encoding which would enable recovery of the data. In [11] the authors proposed a compression algorithm which consists of both lossy and lossless compression stages, using prediction on the receiver to modulate transmission rates while leveraging lossless coding techniques when sending update data. In our use case, we employ a fully-defined compression algorithm on a sensor node within the BSN, which can be easily tuned with a single parameter for a given sensor type.

# 3 Methodology

In this section, we describe the features of our BSN platform, including component devices and capabilities. We then discuss the methods used to compress, encrypt, and publish the sensor data. Finally, we outline the experimental setup.

## 3.1 Platform Design

The platform used in this work is an extensible, programmable node environment that enables rapid prototyping and development of wearable technology through robust visual feedback and efficient use of BSN software and hardware. While the platform functions independent of any external internet or computer connection, it is configured by default to communicate through a WebSocket connection via WiFi or USB with a browser-based, real-time multimodal visualizer.

The physical counterpart to the platform consists of off-the-shelf microcontrollers (ESP32) flashed with custom firmware allowing it to communicate on the BSN platform. Each microcontroller can assume one of two roles: *controller* or *node*. Nodes serve as physical hubs for sensor hardware to interface with, allowing them to broadcast their output to the rest of the network. Controllers
* Documentation

* FAQ

* API

* OAI-PMH

* AuréHAL

## Informations

* À propos

* Données personnelles

* Mentions légales

* Accessibilité

* Conformité RGAA

## Questions juridiques

* Je publie, quels sont mes droits ?

* Loi pour une République numérique

* Stratégie de non-cession des droits

* SHERPA/RoMEO

## Portails

* Portails institutionnels

* HAL

* HAL SHS

* HAL Thèses

* MédiHAL

## CCSD

* CCSD

* Episciences

* Sciencesconf
<figure><img src="image_3.png" /><figcaption>Fig. 2: Flowchart of the proposed BSN platform. The sensors gather a fixed number of samples into individual arrays during data acquisition. Arrays are compressed according to sensor-specific rules, concatenated into packets, encrypted, and finally published to the cloud service.</figcaption></figure>

coordinate communication between nodes, sensors attached to these nodes, and clients intending to access data from the BSN platform. Aside from managing the communications of the platform, controllers may also handle any necessary data pre-processing prior to transmitting to other controllers and/or clients. Specifically, controllers on a configured BSN platform instance can take the data returned by its assigned nodes, compress it, encrypt it, and upload it to an AWS server. A flowchart of the process is shown in Figure 2.

## 3.2 Compression

An efficient compression routine for BSN data must meet certain criteria:

* **Latency:** computation of the compressed packet should not introduce considerable latency

* **Flexibility:** compression should be suitable for varying packet sizes, as different BSN implementations can have different numbers and types of sensors with varying sampling rates

* **Energy Efficiency:** the total computation energy should not exceed the total energy savings due to encrypting and transmitting a smaller packet

* **Tunability:** if lossy, the compression should be configurable, such that different sensors can be compressed to comply with reconstruction constraints

Hence, a lightweight, configurable compression routine, which provides a suitable compression ratio for BSN signals is desired. In particular, we utilize a lifting wavelet transform based on the Haar wavelet, with a per-sensor configurable detail coefficient threshold and efficient run-length encoding scheme. The final packet is optimized to account for the (in)compressibility of different sensors, including those with on-chip classification, which enables us to leverage edge computation capabilities and further reduce packet size.

**Lifting Transform and Configurable Thresholding** We employ a lifting scheme variant of the Haar wavelet transform, which is ideal for conserving
relevant data from body sensors that frequently have extended periods of similar or repetitive readings. Initially, we use lifting stages to separate the fine details in the sensor signal [27]. The split step consists of dividing the sensor signal into even and odd elements. The predictive step (1) is performed, where a linear interpolation function assumes that an odd element will exist at the mid-point of a line between the two even values adjacent to it. The odd element is replaced by whatever difference results from subtracting the odd value's predicted value from its actual value. The update step (2) replaces each even element with an average of both the even element itself and its corresponding odd element. The transform is complete once these steps have been performed on all pairs of even/odd elements. The results of the Haar lifting scheme are easily reversible, such that the original sensor signal can be reconstructed by adding the prediction value back to each odd element and interleaving the even and odd values into one sample array.

$$odd_{j+1,i} = odd_{j,i} - even_{j,i} \qquad (1)$$

$$even_{j+1,i} = even_{j,i} + \frac{odd_{j+1,i}}{2} \qquad (2)$$

Our implementation groups readings from each compressible sensor on the BSN into 16 sample batches. We apply a Level 3 lifting Haar transform, resulting in a transformed signal beginning with two approximation coefficients, which represent the average values of the first half and second half of the original 16-element array, followed by 2, 4, and 8 detail coefficients from levels 3, 2, and 1, respectively. This DWT implementation with the Haar wavelet is computationally inexpensive, requiring few operations per sample and making it ideal for use in this context.

Signals acquired from body sensors (accelerometers, gyroscopes, distance sensors, etc.) often exhibit gradual changes over brief timescales rather than abrupt ones. This yields sequential measurements with similar magnitudes. Such signals, in their transformed state, will have detail coefficients of generally smaller magnitude. A thresholding operation may be applied in the wavelet domain to the detail coefficients to effectively filter minor fluctuations, e.g. noise or less relevant data, making the signal more amenable to compression in subsequent processing stages. In particular, when applied to signals from sensors that do not experience high-magnitude changes, thresholding detail coefficients frequently produces results with large, adjacent groups of zeros in the wavelet domain, which can lead to higher compression ratios, though this comes at the cost of greater reconstruction error [16]. Due to differences in each sensor type and the required fidelity during reconstruction of different signals in different BSN applications, a unique threshold value can be defined for each sensor type. For example, the accelerometer may have a detail coefficient threshold of 3, i.e. any detail coefficient $\le 3$ is set to 0, whereas the gyroscope may have a detail coefficient threshold of 5. This can enable designers to easily trade-off between the compression ratio (and sub-
sequent energy savings from reduced packet transmission), and reconstruction
accuracy on a per-sensor basis.

**Run-Length Encoding and Packet Generation** After thresholding, the packets will generally be sparse, containing multiple segments of consecutive zeros, making it more amenable to compression. Run-length encoding (RLE) is a well-known lossless compression routine in which repeated values in a signal are represented by the number of times that value is repeated ($n_i$) in array $n$, and the value of the data itself, ($b_i$), in array $b$. As with other compression routines, random data, or highly variant data which are not amenable to compression, may result in packets larger than the original array. This is important to consider when determining the array size constants and sensor thresholds, as these choices have a direct impact on the overall efficiency of the compression. We elaborate on this point in Section 3.4.

While much of the data returned by the body sensors is comprised of raw
samples in a time series, some sensors have built-in processing capabilities which
return categorical data. For example, an accelerometer may return the X, Y,
and Z components of acceleration, but a more sophisticated sensor may directly
process this data and attempt to categorize the wearer's current physical activity
such as standing, walking, running, jumping, or climbing stairs. Such categorical
data are not amenable to transform and thresholding, and there is no guarantee
they will naturally repeat, and so compression may not provide any benefit.
Hence, while we consider these data incompressible, they may still be encoded
in fewer bits with efficient atomic operations, e.g. **shift** and **logic OR**. To account
for sensors which may return more than 8 categories, we encode two subsequent
readings from these sensors into one 8-bit byte, thus supporting up to $2^4 = 16$
categories for each sample.

Next, the RLE arrays are concatenated in an optimally space-efficient manner. As each packet contains 16 samples from each sensor, there can be at most 16 repetitions $n_i$ for each value $b_i$. Hence, each element $n_i$ in the $n$ array can also be stored in 4-bit chunks. Moreover, in all but one special case, the total number of non-zero nibbles in the $n$ array provide sufficient information for reconstruction of the $b$ array. This is shown in Fig. 3. For example, the first two bytes, `{0x24, 0x19}` indicate that the subsequent $b$ array contains just 4 elements, as there are four non-zero nibbles totaling 16 - the maximum size of the $b$ array. The expanded array is shown in Figure 3(b), as array $b_0$. Following the 4 bytes of the array $b_0$, a new $n$ array begins. While this also consists of 2 bytes, the least significant nibble in the 2nd byte is 0; hence, there are 3 non-zero nibbles whose values sum to 16. This indicates that the next three elements comprise the corresponding $b$ array. In $n_2$, only 1 byte is needed to define the elements of the $b$ array - **0x2E** - as the nibbles **0x2** and **0xE** sum to 16. Hence, the next two bytes define the corresponding $b$ array. Finally, in the special case of $n_3$, a **0x0** is encountered in the lower half of the byte, but the preceding nibble is **0xF**. This does not sum to 16, but does represent a situation where there are 16 repeated values (in this case, **0x00**) with just one element. If the lower nibble were **0x01**,
<figure><img src="image_4.png" /><figcaption>Fig. 3: Example of RLE sensor data: (a) the individual nibbles of the first two bytes (0x2, 0x4, 0x1, and 0x9) sum to 16, which indicates that the *n* array is complete, and that there are 4 bytes in the *b* array - 0xF2, 0x20, 0xC1, and 0x5A. These are expanded according to the RLE decoding rules in *b*₀, shown in subfigure (b). Other *n/b* array pairs show other possible results from the RLE process, including a special case in *b*₃. (b) the expanded sensor data packets.</figcaption></figure>

this would have indicated two bytes in the corresponding *b* array, rather than just one. Thus, there is no need to store the size of the *n* and *b* arrays, and it can be efficiently stored and perfectly reconstructed from this encoding. In the worst case, in which no element of *b* is repeated, the overhead from this encoding is exactly 50%. Due to the previously described wavelet transform and per-sensor thresholding approach, such a situation is extremely rare for the BSN data.

The final packet is therefore comprised of a concatenation of the encoded categorical data with concatenated run-length encoded arrays, as shown in Figure 4. The maximum size of the packet depends on the number of categorical sensors, the number of raw data sensors, and the compression ratio for that data across the 16 samples. For example, with 3 categorical sensors, 16 samples of 1 byte each (unencoded) would require 48 bytes; with the proposed encoding, this is reduced to 24 bytes. With 10 raw data sensors, assuming 8 bits per sample, and 16 samples per sensor per packet, a total of 160 bytes are required. If there are no repeated values whatsoever, the proposed encoding would require 8 bytes per *n* array and 16 bytes per *b* array, for each sensor, or 240 bytes - an increase of 50%. If about half of the values are repeated, the *n* + *b* array size for each sensor would be about 12, for an overall size of 120 bytes, a savings of 25%. In practice, at least 33% of the values should be compressible in this manner to effectively reduce the size of the complete data packet comprised of the compressible sensor data. Example compression ratios for various sensors and thresholds are given in
<figure><img src="image_5.png" /><figcaption>Fig. 4: The final packet is comprised of paired nibbles of categorical sensor data, followed by concatenated run-length encoded arrays for the sensors. These arrays represent thresholded data from the sensors in the wavelet domain. The *n* array are packed into nibbles, while elements of the *b* array are then appended. The MQTT header and control bytes are prepended prior to transmission.</figcaption></figure>

Section 4, where we also consider the energy savings due to reduced transmission time, as well as overall energy efficiency.

## 3.3 Encryption

The limited computational capability and memory availability of the microcontrollers comprising our BSN platform create a need for algorithms that can perform cryptographic operations reliably on systems with limited resources. There are a number of lightweight cryptography algorithms which have emerged for use in IoT. For this implementation, we have chosen SPARX, a lightweight block cipher readily implemented on constrained platforms [9]. Traditional block ciphers often have elaborate key schedules designed to work on 32-bit or greater architectures. Using these ciphers on sub 32-bit architectures can cause register pressure to increase, forcing round keys to be either computed at runtime or pre-computed and stored in RAM [20]. Even 32-bit systems are hindered by the S-box operations required by many modern encryption standards, further re-enforcing the need for a microcontroller-appropriate alternative.

SPARX is an ideal cipher for this platform because it includes functionality to pre-compute the round keys as well as a variant designed specifically to work well on architectures of 32 bits or less. This is possible because all internal operations are implemented using 16-bit variables. The variant of SPARX used in this work is referred to as SPARX 64-128, denoting that it is configured to encrypt a 64-bit block with a 128-bit key. Because residual bits that exceed the length of the information being processed must still be encrypted, having a smaller blocksize can be advantageous in situations where lower latency and energy are required. In general, this can reduce space wasted due to padding during encryption/decryption. This advantage becomes increasingly apparent when the size of the encrypted message approaches the theoretical minimum packet size of 56 bytes, which is evenly divisible by 64 bits, but not 128 or 256. If a 128-bit or 256-bit block were used, some of the benefits of compression would
be undone due to the required padding, and the encryption operation would need
to process additional irrelevant data.

## 3.4 Cloud Uploading and Processing

After compression and encryption of the sensor data has been completed, the data is then uploaded to an AWS server. This was accomplished with an AWS instance with the IoT platform enabled. AWS IoT is a managed cloud platform for secure interactions between connected devices and cloud appliances. In order for microcontrollers on the BSN platform to communicate with the AWS IoT cloud platform, they must be configured with the appropriate connection parameters and credentials. Amazon has created a C++ library to facilitate initializing and maintaining communication between AWS servers and IoT cloud platform devices [2]. We generated the necessary security certificates on the AWS website and exported them to a file included in the programming that was uploaded to each device, giving them provisioned access to AWS IoT cloud resources. For our use, we only needed AWS IoT to listen to incoming data from a configured microcontroller, so although the ability to receive messages from AWS IoT was operational, we did not utilize it for the scope of this research. Nevertheless, we maintained low-latency communication with the server, such that cloud-based computation and feedback to BSN-based actuators would be feasible.

The communication protocol used internally by the AWS library is based on MQTT, a lightweight, publish-subscribe network protocol running over TCP/IP. While MQTT is usually used to send and receive JSON data, it is also capable of passing raw binary data, which was our use case for this platform. We published MQTT data in raw binary form rather than JSON or string data to reduce message size overhead as much as possible. Since each reading was converted into a one-byte representation of its original value, this avoids recasting the data into ASCII and consuming additional space with the structuring of JSON.

## 3.5 Experimental Setup

Our BSN testbed consisted of a microcontroller flashed with the platform firmware connected to an Inertial Measurement Unit (IMU) and two distance sensors. The IMU itself contains many separate sensing components, such as an accelerometer, gyroscope, and magnetometer, for a total of 21 sensors, which were sampled at 2 Hz. To explore the potential trade-offs in preparing data for publishing to the cloud, four separate packet processing schemes were tested in real-time, each consisting of two or more primary functions: 1) **CP: concatenate and publish**; 2) **CCP: compress, concatenate, and publish**; 3) **CEP: concatenate, encrypt, and publish**; and 4) **CCEP: compress, concatenate, encrypt, and publish**.

A National Instruments (NI) Analog Discovery (AD) 2 USB oscilloscope was used to gather all power measurements. A 2.2 Ω shunt resistor was connected in series with the system power. Differential measurements were taken across the resistor at 50 MHz using the two analog inputs. A third, digital channel was used to trigger measurement; a digital GPIO pin on the microcontroller was
asserted at startup, deasserted immediately before the function under test, and
immediately reasserted once the function had returned. This capture window
was recorded in 100 sequential measurements, which were aligned according to
the recorded digital trigger signal and averaged together to improve signal qual-
ity. Execution of the `compress()`, `concatenate()`, and `encrypt()` functions is
very consistent across measurements in different processing schemes; however the
latency of the `publish()` function may depend on a number of external factors.
To ensure as little variance as possible in measurements of the `publish()` func-
tion, we ensured only the BSN was connected to the WiFi network, and placed
the BSN in close proximity to the router. In total, two datasets were processed
in real-time on the sensor nodes: one in which the BSN was in motion, and one
while it was still. These are referred to as the `walking` and `standing` datasets.
Together, these demonstrate the capabilities of the system when using different
packet processing schemes under real-world conditions.

# 4 Results and Discussion

An instance of the BSN platform was implemented as described in Section 3.
Communication with AWS was confirmed by viewing the packets published on
the MQTT channel. From here, packets can be decrypted, decoded, and further
processed or graphed, or simply stored for later viewing. In this section, we
provide detailed results and an analysis of our experiments with respect to the
compression routine when applied to diverse sensor data from the example BSN,
as well as overall efficiency of the packet processing schemes.

## 4.1 Compression

In general, the compression scheme worked well on most of the sensor data. Table 1 gives an overview of the compression ratios and resulting reconstruction error, computed as RMSE, as a percentage of the total sensing range when applied to the *walking* dataset. As each sensor type has a unique range of possible values, all of which are mapped to 8-bit values during processing, reporting the error in this manner provides a fair comparison between different sensor types. Furthermore, we define the compression ratio (CR) as the percent reduction in size; hence, a CR of 25% indicates the compressed packet is 25% smaller than the original, while a CR of 75% indicates the compressed packet is 75% smaller than the original. Among the least compressible signal types in the dataset included the accelerometry signals (Accel. and LinAccel.), which required relatively high threshold parameter ($T_d$) ranges to achieve compression, and then resulted in moderate reconstruction error, e.g. about 5%. Since $T_d$ is tunable, it is feasible to adjust this parameter for different sensor types, or even signals from different measurement axes if desired. On average across all sensor types, this technique achieves a minimum of 28.5% compression with an average reconstruction error of 2.0%, typical compression of 46.4% with an average reconstruction error of 5.3%, and maximum compression of 53.2% with an average reconstruction
error of 6.0%. By comparison, compression achieved on the *standing* dataset tends to be higher, with lower error. At all threshold levels which provide suitable compression for sensors while active, as in the walking dataset, maximum packet compression (81.3% or 68.8%, depending on the signal) is achieved at an average reconstruction error of under 0.1%. These results confirm the selection of the 3rd level Haar lifting wavelet transform and configurable threshold, which ultimately provided an acceptable balance between minimum sensor packet compression, processing time, and resulting reconstruction error for $T_d > 0$.

<table><caption>Table 1: Compression (% reduction) and reconstruction error for various threshold values on data from the IMU and distance sensors on the walking dataset.</caption><thead><tr><th>Sensor</th><th>T<sub>d</sub></th><th>CR (%)</th><th>Er (%)</th><th>T<sub>d</sub></th><th>CR (%)</th><th>Er (%)</th><th>T<sub>d</sub></th><th>CR (%)</th><th>Er (%)</th></tr></thead><tbody><tr><td rowspan="3">Accel.</td><td colspan="3">X</td><td colspan="3">Y</td><td colspan="3">Z</td></tr><tr><td>25</td><td>6.3</td><td>3.1</td><td>-</td><td>-</td><td>-</td><td>25</td><td>25.0</td><td>4.2</td></tr><tr><td>50</td><td>43.8</td><td>6.0</td><td>50</td><td>6.3</td><td>10.1</td><td>50</td><td>50.0</td><td>6.4</td></tr><tr><td></td><td>75</td><td>50.0</td><td>7.5</td><td>75</td><td>43.8</td><td>12.1</td><td>75</td><td>68.8</td><td>7.6</td></tr><tr><td rowspan="3">Dist.</td><td colspan="3">Right</td><td colspan="3">Left</td><td colspan="3"></td></tr><tr><td>8</td><td>12.5</td><td>1.3</td><td>8</td><td>6.3</td><td>0.0</td><td></td><td></td><td></td></tr><tr><td>12</td><td>50.0</td><td>1.6</td><td>12</td><td>6.3</td><td>0.0</td><td></td><td></td><td></td></tr><tr><td></td><td>15</td><td>68.8</td><td>1.9</td><td>15</td><td>6.3</td><td>0.0</td><td></td><td></td><td></td></tr><tr><td rowspan="3">Euler</td><td colspan="3">Roll</td><td colspan="3">Pitch</td><td colspan="3">Yaw</td></tr><tr><td>8</td><td>25.0</td><td>1.0</td><td>2</td><td>31.3</td><td>0.3</td><td>2</td><td>12.3</td><td>0.3</td></tr><tr><td>15</td><td>31.3</td><td>1.5</td><td>5</td><td>68.8</td><td>0.4</td><td>3</td><td>50.0</td><td>0.4</td></tr><tr><td></td><td>20</td><td>68.8</td><td>2.2</td><td>**</td><td>**</td><td>**</td><td>5</td><td>81.3</td><td>0.6</td></tr><tr><td rowspan="3">Gyro.</td><td colspan="3">X</td><td colspan="3">Y</td><td colspan="3">Z</td></tr><tr><td>25</td><td>6.3</td><td>3.6</td><td>25</td><td>25.0</td><td>3.9</td><td>25</td><td>12.5</td><td>3.7</td></tr><tr><td>50</td><td>25.0</td><td>5.5</td><td>50</td><td>50.0</td><td>5.9</td><td>50</td><td>50.0</td><td>5.7</td></tr><tr><td></td><td>**</td><td>**</td><td>**</td><td>**</td><td>**</td><td>**</td><td>**</td><td>**</td><td>**</td></tr><tr><td rowspan="3">LinAccel.</td><td colspan="3">X</td><td colspan="3">Y</td><td colspan="3">Z</td></tr><tr><td>40</td><td>6.3</td><td>3.1</td><td>-</td><td>-</td><td>-</td><td>20</td><td>6.3</td><td>2.2</td></tr><tr><td>50</td><td>12.3</td><td>6.9</td><td>-</td><td>-</td><td>-</td><td>40</td><td>31.3</td><td>5.0</td></tr><tr><td></td><td>60</td><td>31.3</td><td>7.8</td><td>-</td><td>-</td><td>-</td><td>50</td><td>62.3</td><td>7.7</td></tr><tr><td rowspan="3">Magneto.</td><td colspan="3">X</td><td colspan="3">Y</td><td colspan="3">Z</td></tr><tr><td>1</td><td>81.3</td><td>0.0</td><td>1</td><td>81.3</td><td>0.0</td><td>1</td><td>81.3</td><td>0.0</td></tr><tr><td>**</td><td>**</td><td>**</td><td>**</td><td>**</td><td>**</td><td>**</td><td>**</td><td>**</td></tr><tr><td></td><td>**</td><td>**</td><td>**</td><td>**</td><td>**</td><td>**</td><td>**</td><td>**</td><td>**</td></tr><tr><td rowspan="3">Quatern.</td><td colspan="3">X</td><td colspan="3">Y</td><td colspan="3">Z</td></tr><tr><td>3</td><td>6.3</td><td>0.4</td><td>3</td><td>68.8</td><td>0.3</td><td>3</td><td>68.8</td><td>0.3</td></tr><tr><td>5</td><td>25.0</td><td>0.6</td><td>**</td><td>**</td><td>**</td><td>**</td><td>**</td><td>**</td></tr><tr><td></td><td>10</td><td>68.8</td><td>1.1</td><td>**</td><td>**</td><td>**</td><td>**</td><td>**</td><td>**</td></tr></tbody><tfoot><tr><td colspan="10">- no suitable threshold could be found for the maximum allowable error</td></tr><tr><td colspan="10">** optimal compression already achieved at a lower threshold</td></tr></tfoot></table>
## 4.2 Packet Processing Efficiency

To ensure security of the final system and that the privacy of the end user is protected, the data gathered by the BSN must be encrypted in some way prior to publishing. Because the packet sizes are relatively small, we did not observe an appreciable difference in the latency of the `publish()` function, which was responsible for generating the final MQTT packet and transmitting the data to the remote server via WiFi. It is expected that, for a simpler communication protocol, differences in the actual transmission latency, as measured on the radio itself, would be more apparent, and the latency/energy savings due to reduced packet size would be significantly more pronounced. Therefore, while the CP and CCP variants are included as a reference, the more meaningful comparison is between CEP and CCEP.

Figure 5 shows the total current consumption of the complete system during one full period of packet processing for the `walking` and `standing` datasets. Vertical lines in the graphs indicate the end of a processing stage; for example, in Walking CEP, the three vertical lines indicate the end of the Compression, Encryption, and Publishing stages. In this implementation, there is a high baseline power, but in practice, any number of common power saving strategies may be employed to improve battery life. While actively processing, there is about 100mA in current over the baseline; this first segment includes all but the `publish()` function, which itself takes around 4ms. Broadly, our results demonstrate that the net energy efficiency is improved in CCEP when compared to CEP due primarily to the smaller packet size, translating to less data that must undergo encryption; this is most evident when comparing the relative Energy-Delay Product (EDP) difference between CCEP and CEP on the `walking` and `standing` datasets. Note that in these results, lossless compression ($T_d = 0$) was used; in practice, a higher $T_d$ would improve compression, as shown in Table 1.

With this setup, the average time to encrypt a raw data packet in CEP was 737 µS, whereas the time required to encrypt a compressed packet was only 250 µS for the `standing` data and 531 µS on the `walking` data. Meanwhile, compressing the `standing` data required only 58 µS, while compressing the `walking` data required 66 µS. Because the concatenate function execution depends on the type of data (encrypted or raw), there is also variance here: for uncompressed data, concatenation required 3.5 µS, whereas for compressed `walking` and `standing` data, concatenation required 2.8 µS and 1.5 µS, respectively. When considering the latency and energy of just these three functions in preparing packets for publishing, there is a marked improvement in energy efficiency, 34% and 82%, for compressed data relative to uncompressed data, for the `walking` and `standing` datasets, respectively. Overall EDP, which includes publishing, is shown in Figure 6(a). Here, there is a significant improvement in energy efficiency due to compression in the `standing` dataset, and the primary driver - the improvement in latency - is clearly shown in Figure 6(b).
<figure><img src="image_6.png" /><figcaption>Fig. 5: Power measurements for walking and standing data. Vertical lines in the graphs denote the end of a processing stage.</figcaption></figure>
<figure><img src="image_7.png" /><figcaption>Fig. 6: Average (a) energy efficiency and (b) execution time for different packet processing schemes on the two datasets. Note that for EDP, lower values indicate higher efficiency.</figcaption></figure>

## 5 Conclusion

In this paper, we have presented a cloud-connected BSN platform that features lightweight cryptography and a configurable compression algorithm suitable for constrained devices. We have demonstrated through rigorous experimental verification how the compression can be applied to diverse types of sensor data, achieving average compression of 46% with about 5% error in the typical case. We have also presented an efficient packet encoding scheme which supports an arbitrary number of categorical sensors, each of which supports up to 16 categories, as well as an optimal organization for run-length encoded data from the compression routine. Our platform supports connection to Amazon AWS IoT using a lightweight MQTT protocol. In general, the use of a secure lightweight cipher is encouraged to ensure security for the system, and privacy for the individual. We have demonstrated how a sufficiently low-overhead compression algorithm can actually enable energy savings, even when used in conjunction with a lightweight block cipher. Future work on this platform includes implementing additional power optimization strategies, investigating alternative compression routines, and overall usability enhancements for BSN developers.

## References

1. Alrige, M., Chatterjee, S.: Toward a taxonomy of wearable technologies in health-care. In: Donnellan, B., Helfert, M., Kenneally, J., VanderMeer, D., Rothenberger, M., Winter, R. (eds.) New Horizons in Design Science: Broadening the Research Agenda. pp. 496–504. Springer International Publishing, Cham (2015)
2. Amazon.com Inc.: AWS IoT Device SDK for C++ v2 (Jun 2021), https://github.comaws/aws-iot-device-sdk-cpp-v2

3. Azar, J., Darazi, R., Habib, C., Makhoul, A., Demerjian, J.: Using dwt lifting scheme for lossless data compression in wireless body sensor networks. In: 2018 14th International Wireless Communications Mobile Computing Conference (IWCMC). pp. 1465–1470 (2018). https://doi.org/10.1109/IWCMC.2018.8450459

4. Beaulieu, R., Shors, D., Smith, J., Treatman-Clark, S., Weeks, B., Wingers, L.: The simon and speck lightweight block ciphers. In: Proceedings of the 52nd Annual Design Automation Conference. DAC ’15, Association for Computing Machinery, New York, NY, USA (2015). https://doi.org/10.1145/2744769.2747946

5. Bogdanov, A., Knudsen, L.R., Leander, G., Paar, C., Poschmann, A., Robshaw, M.J.B., Seurin, Y., Vikkelsoe, C.: Present: An ultra-lightweight block cipher. In: Paillier, P., Verbauwhede, I. (eds.) Cryptographic Hardware and Embedded Systems - CHES 2007. pp. 450–466. Springer Berlin Heidelberg, Berlin, Heidelberg (2007)

6. Dey, N., Ashour, A.S., Shi, F., Fong, S.J., Sherratt, R.S.: Developing residential wireless sensor networks for ecg healthcare monitoring. IEEE Transactions on Consumer Electronics 63(4), 442–449 (2017). https://doi.org/10.1109/TCE.2017.015063

7. Diehl, W., Farahmand, F., Yalla, P., Kaps, J.P., Gaj, K.: Comparison of hardware and software implementations of selected lightweight block ciphers. In: 2017 27th International Conference on Field Programmable Logic and Applications (FPL). pp. 1–4 (2017). https://doi.org/10.23919/FPL.2017.8056808

8. Dinu, D., Corre, Y.L., Khovratovich, D., Perrin, L., Großschädl, J., Biryukov, A.: Triathlon of lightweight block ciphers for the internet of things. Journal of Cryptographic Engineering 9(3), 283–302 (Sep 2019)

9. Dinu, D., Perrin, L., Udovenko, A., Velichkov, V., Großschädl, J., Biryukov, A.: Design Strategies for ARX with Provable Bounds: Sparx and LAX. In: Cheon, J.H., Takagi, T. (eds.) Advances in Cryptology – ASIACRYPT 2016. pp. 484–513. Springer Berlin Heidelberg, Berlin, Heidelberg (2016). https://doi.org/10.1007/978-3-662-53887-6 18

10. Elsayed, M., Badawy, A., Mahmuddin, M., Elfouly, T., Mohamed, A., Abualsaud, K.: Fpga implementation of dwt eeg data compression for wireless body sensor networks. In: 2016 IEEE Conference on Wireless Sensors (ICWiSE). pp. 21–25 (2016). https://doi.org/10.1109/ICWISE.2016.8187756

11. Giorgi, G.: A combined approach for real-time data compression in wireless body sensor networks. IEEE Sensors Journal 17(18), 6129–6135 (2017). https://doi.org/10.1109/JSEN.2017.2736249

12. Gravina, R., Alinia, P., Ghasemzadeh, H., Fortino, G.: Multi-sensor fusion in body sensor networks: State-of-the-art and research challenges. Information Fusion 35, 68–80 (2017)

13. Gravina, R., Fortino, G.: Wearable body sensor networks: State-of-the-art and research directions. IEEE Sensors Journal 21(11), 12511–12522 (2021). https://doi.org/10.1109/JSEN.2020.3044447

14. Habib, C., Makhoul, A., Darazi, R., Couturier, R.: Health Risk Assessment and Decision-Making for Patient Monitoring and Decision-Support using Wireless Body Sensor Networks. Information Fusion 47, 10–22 (2019)

15. Jones, R.W., Katzis, K.: 5g and wireless body area networks. In: 2018 IEEE Wireless Communications and Networking Conference Workshops (WCNCW). pp. 373–378 (2018). https://doi.org/10.1109/WCNCW.2018.8369035
16. Karam, R., Majerus, S.J., Bourbeau, D.J., Damaser, M.S., Bhunia, S.: Tunable and lightweight on-chip event detection for implantable bladder pressure monitoring devices. IEEE Transactions on Biomedical Circuits and Systems 11(6), 1303–1312 (Dec 2017). https://doi.org/10.1109/tbcas.2017.2748981

17. Li, Y., Qi, X., Keally, M., Ren, Z., Zhou, G., Xiao, D., Deng, S.: Communication energy modeling and optimization through joint packet size analysis of bsn and wifi networks. IEEE Transactions on Parallel and Distributed Systems 24(9), 1741–1751 (2013). https://doi.org/10.1109/TPDS.2012.264

18. Mohd, B.J., Hayajneh, T.: Lightweight block ciphers for iot: Energy optimization and survivability techniques. IEEE Access 6, 35966–35978 (2018). https://doi.org/10.1109/ACCESS.2018.2848586

19. Mohd, B.J., Hayajneh, T., Ahmad Yousef, K.M., Khalaf, Z.A., Bhuiyan, M.Z.A.: Hardware design and modeling of lightweight block ciphers for secure communications. Future Generation Computer Systems 83, 510–521 (2018)

20. Mouha, N., Mennink, B., Van Herrewege, A., Watanabe, D., Preneel, B., Verbauwhede, I.: Chaskey: An efficient mac algorithm for 32-bit microcontrollers. In: Joux, A., Youssef, A. (eds.) Selected Areas in Cryptography – SAC 2014. pp. 306–323. Springer International Publishing, Cham (2014)

21. Muzammal, M., Talat, R., Sodhro, A.H., Pirbhulal, S.: A multi-sensor data fusion enabled ensemble approach for medical data from body sensor networks. Information Fusion 53, 155–164 (2020)

22. Pirbhulal, S., Wu, W., Li, G., Sangaiah, A.K.: Medical information security for wearable body sensor networks in smart healthcare. IEEE Consumer Electronics Magazine 8(5), 37–41 (2019). https://doi.org/10.1109/MCE.2019.2923925

23. Puthal, D., Wu, X., Surya, N., Ranjan, R., Chen, J.: Seen: A selective encryption method to ensure confidentiality for big sensing data streams. IEEE Transactions on Big Data 5(3), 379–392 (2019). https://doi.org/10.1109/TBDATA.2017.2702172

24. Qiu, H., Qiu, M., Lu, Z.: Selective encryption on ecg data in body sensor network based on supervised machine learning. Information Fusion 55, 59–67 (2020). https://doi.org/10.1016/j.inffus.2019.07.012

25. Sehrawat, D., Gill, N.: Lightweight Block Ciphers for IoT based applications: A Review. International Journal of Applied Engineering (05 2019)

26. Solanas, A., Patsakis, C., Conti, M., Vlachos, I.S., Ramos, V., Falcone, F., Postolache, O., Perez-martinez, P.A., Pietro, R.D., Perrea, D.N., Martinez-Balleste, A.: Smart health: A context-aware health paradigm within smart cities. IEEE Communications Magazine 52(8), 74–81 (2014). https://doi.org/10.1109/MCOM.2014.6871673

27. Sweldens, W.: The lifting scheme: A construction of second generation wavelets. SIAM journal on mathematical analysis 29(2), 511–546 (1998)

28. Wang, Q., Dai, H.N., Zheng, Z., Imran, M., Vasilakos, A.V.: On connectivity of wireless sensor networks with directional antennas. Sensors 17(1) (2017). https://doi.org/10.3390/s17010134

29. Wang, S., Ji, L., Li, A., wu, J.: Body sensor networks for ubiquitous healthcare. Journal of Control Theory and Applications 9, 3–9 (02 2011). https://doi.org/10.1007/s11768-011-0236-7

30. Yang, G., Zhu, B., Suder, V., Aagaard, M.D., Gong, G.: The simeck family of lightweight block ciphers. In: Güneysu, T., Handschuh, H. (eds.) Cryptographic Hardware and Embedded Systems – CHES 2015. pp. 307–329. Springer Berlin Heidelberg, Berlin, Heidelberg (2015)