Content uploaded by Byounghyun Yoo
Author content
All content in this area was uploaded by Byounghyun Yoo on Jan 03, 2024
Content may be subject to copyright.
Internet of Things 25 (2024) 101014
Available online 25 November 2023
2542-6605/© 2023 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY license
(http://creativecommons.org/licenses/by/4.0/).
Addressing IoT storage constraints: A hybrid architecture for
decentralized data storage and centralized management
Chanhyuk Lee
a
,
1
, Jisoo Kim
b
,
1
, Heedong Ko
a
, Byounghyun Yoo
a
,
c
,
*
a
Center for Articial Intelligence, Korea Institute of Science and Technology, 5 Hwarangro14-gil, Seongbuk-gu, Seoul, 02792, Republic of Korea
b
Department of Articial Intelligence, Jeju National University, 102 Jejudaehak-ro, Jeju-si, Jeju Special Self-Governing Province, 63243, Republic of
Korea
c
AI-Robotics, KIST School, Korea National University of Science and Technology, 5 Hwarangro14-gil, Seongbuk-gu, Seoul, 02792, Republic of Korea
ARTICLE INFO
Keywords:
Decentralized data storage
Internet of Things
InterPlanetary File System
Industrial applications
ABSTRACT
As blockchain and AI technologies advance, industrial applications increasingly rely on IoT de-
vices for continuous, massive data collection. However, these devices have storage limitations
when dealing with extensive data streams. The InterPlanetary File System (IPFS), a decentralized
storage solution, addresses these constraints. However, IPFS’s signicant time requirement for
data recording introduces a new challenge. Furthermore, its Content IDentiers (CIDs) do not
inherently convey the source device’s identity or associated metadata, adding complexity to
specic condition-based data retrieval. These factors hinder the discernment of the current data
state, preventing IoT devices from clearing storage space by deleting unnecessary data. Conse-
quently, this results in inadequate storage capacity for IoT devices, posing an obstacle to col-
lecting and transmitting large data. Our study proposes a hybrid architecture to address these
challenges, integrating the decentralized storage capabilities of IPFS with a centralized CID
management system. This architecture employs Message Queuing Telemetry Transport (MQTT)
for efcient CID transfer and a database for archiving CID values and associated metadata. Using
the archived metadata, IoT devices determine the status of the data and perform tasks accord-
ingly. This enables effective storage management for IoT devices by removing data that has
already been uploaded and is safe for deletion. Our architecture demonstrates versatility, ac-
commodating data of varying sizes, formats, and frequencies. We validated our approach through
an extensive 100-hour experiment, successfully collecting 356 GB of data from diverse sensors.
These results underscore the robustness and adaptability of our architecture, emphasizing its
potential for a range of IoT applications.
1. Introduction
The 4th industrial revolution has led to massive data transformation through the use of IoT devices [1–5]. As blockchain and AI
technologies advance, the need for signicant amounts of data increases [6–15]. Data storage in IoT edge devices presents a signicant
challenge due to insufcient memory space, making it essential to transfer and store data using an additional system. Centralized
systems, such as cloud computing, are popular for storing big data in IoT because of their convenience and low cost, with Amazon Web
* Corresponding author.
E-mail address: yoo@byoo.org (B. Yoo).
1
These authors share equal contribution.
Contents lists available at ScienceDirect
Internet of Things
journal homepage: www.sciencedirect.com/journal/internet-of-things
https://doi.org/10.1016/j.iot.2023.101014
Internet of Things 25 (2024) 101014
2
Service (AWS) being a notable example. However, centralized systems have several problems, including severe bottlenecks [16,17].
The increase in IoT devices and trafc exacerbates network issues by requiring large data transfers.
Centralized systems are not recommended for reducing latency or improving scalability. They also face security issues, such as
DDoS attacks and data leakage, since all data is stored on the cloud [18]. Furthermore, only a few countries and companies possess
clouds capable of storing personal data from devices. To address these problems, a decentralized data storage system that enables
low-latency, scalable data storage is proposed. This approach allows individuals to have data sovereignty, where they can decide and
access their collected data [19].
Consequently, we propose a system based on decentralized data storage with centralized management for real-time imple-
mentation. However, fully decentralizing the storage system components is inefcient. While decentralized management, such as
blockchain, offers benets, it leads to implementation challenges in real-world IoT cases due to the signicantly longer time required to
record data compared to a database. Although databases do not ensure immutability, they can store data in pseudo-real-time and offer
high querying abilities, resulting in a robust architecture [20].
We employ the InterPlanetary File System (IPFS), a protocol well-suited for decentralized data storage. IPFS enables distributed
storage of multiple les or data with peer-to-peer communication [21] and can be used in resource-constrained devices, such as
Raspberry Pi. However, a system that solely relies on IPFS lacks robustness, making it necessary to manage the Content IDentier
(CID), which is cryptographically hashed after adding the le to IPFS. Our proposed system integrates IPFS with the message queuing
telemetry transport (MQTT) protocol and a database for CID management. The CID is transferred using MQTT based on its topic, and a
database archives the CID for easy status recognition.
The major contributions of this study are as follows:
•Hybrid data architecture combined with IPFS, a decentralized data storage system with strength points at scalability, security, and
immutability, and centralized CID management to address large and frequent data transfer systems.
•An architecture with long-term endurance suitable for use in resource-limited devices.
•Robustness of the proposed architecture demonstrated through a continuous 100-hour experiment handling 356 GB of data. Proof
of a single IoT device collecting data of up to 68.6 GB, doubling its maximum storage capacity of 32 GB.
•Versatility in managing multi-sensor data, including visual, audio, and Wi-Fi channel state information.
The following section presents relevant studies that propose data transfer architectures using IPFS in the IoT eld. Section 3 details
the primary components of our system and explains the rationale behind selecting this protocol. Section 4 provides an overview of the
system architecture and implementation for each device, followed by a discussion of the experimental results and the novelty of the
proposed architecture in Section 5. Finally, Section 6 offers concluding remarks.
Table 1
Comparison with related works.
Research Implementation CID, Metadata
Processed data
amount
Implemented domain Edge-device
storage
management
IPFS
private
swarm
Archiving
metadata
CID storage CID
communications
(Wang, 2019)
[25]
N/A (Not
implemented)
Video surveillance X O X Blockchain Blockchain
(Sultana,
2020)
[26]
Several les Media image sharing X X O Blockchain Blockchain
(Ortega,
2020)
[27]
8 H, 44.1MB Vehicular network X O O Road-side init IPNS
(Oktian,
2021)
[28]
N/A IoT domain X X O Blockchain,
Database
Blockchain
(Nguyen,
2021)
[29]
Several les Healthcare X O O Blockchain Data ofoading
(Li, 2021)
[30]
N/A IoT domain X X O Blockchain MQTT, CoAP
(Shahjalal,
2022)
[31]
Several les Temperature, humidity,
and dust sensors
X X O Blockchain MQTT, HTTP with
LoRaWAN
(Dammak,
2022)
[32]
Several les Healthcare sensors X X O Blockchain MQTT with
LoRaWAN
Proposed 100 H, 356 GB Visual, audio, Wi-Fi CSI,
and environment
sensors
O O O Database MQTT
C. Lee et al.
Internet of Things 25 (2024) 101014
3
2. Related work
This section analyses studies related to data storage systems utilizing IPFS in the IoT domain.
Blockchain technology, known for its decentralized nature with immutability, transparency, and elimination of intermediaries, is a
signicant player in creating decentralized systems [22]. When combined with IoT, blockchain can offer decentralized data storage
and protection through edge computing [23]. A novel blockchain-based secure data storage protocol for sensors has been developed
[24]. Several studies have proposed decentralized systems using IPFS, with Table 1 listing the features of these architectures. Research
on decentralized systems, including IPFS, has predominantly focused on transmitting small data volumes, typically within the range of
a few megabytes. However, recent advancements in IoT technology have necessitated the transfer of substantial data volumes, often
reaching hundreds of gigabytes. This amount of data transmission signicantly surpasses the storage capacity of most IoT devices,
which typically operate within the gigabyte range. Consequently, it is imperative to monitor the status of data that has been trans-
mitted, allowing for actions referring to the situation, such as reinitiating the transmission of incomplete data or deleting unnecessary
data.
Video surveillance systems that employ permission blockchain, edge computing, and IPFS have been suggested [25]. A secure
medical image-sharing system based on zero-trust principles and blockchain technology with IPFS was provided [26]. Exchanging
semantic distributed data for V2X communications with IPFS and IPNS was proposed and implemented, with all distributed data stored
in the Road-Side Unit (RSU) and vehicles. The experiment was conducted for 8 h, and the protocols were compared. Permission
Ethereum blockchain enhances security, and large les (250 KB - 1000 KB) require a mean-retrieval time of 6.83 s [27]. A conceptual
architecture for decentralizing computing via IPFS and blockchain was introduced [28]. The Ethereum smart contract became a P2P
computing overlay, IPFS storage became a P2P storage overlay, and the SDN controllers and switches became the P2P networking
overlay. A decentralized health architecture, BEdgeHealth, which reduces network latency in authentication without a central third
party, has been proposed [29]. A conceptual architecture for a lightweight and secure-edge computing-based blockchain was provided
[30]. It uses CoAP for the interaction between the edge layer and perception layer and MQTT for CID transfer between the edge and
cloud layers. A secure LoRaWAN system for IoT with an IPFS and blockchain was demonstrated [31]. They implemented a system that
stores the sensor data in the IPFS and metadata in the blockchain. The healthcare monitoring system is adopted based on blockchain
and LoRa communications through MQTT [32].
To solve the problem of centralized cloud computing, which is focused on all the connections to the core system, the concept of Fog
computing, structured as ’cloud – fog - edge,’ has been proposed. [33] Research is underway to implement decentralized systems like
IPFS in the segment that bridges the fog and edge layers [34–36].
Most of the aforementioned studies did not consider robustness. However, our proposed system was developed considering the
robustness in mind, utilizing core components protocols and operating successfully for 100 continuous hours. We employed four types
of sensors, including audio, visual, Wi-Fi CSI, and environmental (humidity, temperature, CO2, and PM2.5), with different le formats:
WAV, H.264, CSV, and JSON. This result indicates that the proposed system can be utilized in multiple domains. Storage clearing in
edge devices with limited memory was not considered in any of the references. It is essential to achieve robustness by preventing
memory errors in edge devices. A few studies have used a private swarm to support security, while others have employed alternative
authentication methods. Using smart contract-based access control with public key request for authentication has been proposed [29].
Fig. 1. Requirement and solution of core elements in the proposed system.
C. Lee et al.
Internet of Things 25 (2024) 101014
4
The encrypted message in the IPFS public swarm veries security instead of the IPFS private swarm [31].
In most cases, architecture archives metadata, including CID, le name, creation date and time. However, various communication
methods were used; such as, blockchain [26], IPNS [27], and MQTT and HTTP by LoRaWAN [31]. These methods have their ad-
vantages and disadvantages. In our case, we require a lightweight message transfer protocol for IoT edge devices, so we deployed the
MQTT protocol to exchange messages and provide a data hierarchy using the MQTT topic.
The most dominant method for storing metadata and CID is blockchain. However, blockchain storage demands much more time to
record the data CID and metadata with multiple IoT device participants. This is a critical issue for implementation. A tradeoff exists
between ensuring data stability and pseudo-real-time storage with high querying abilities. While using a database does not guarantee
data stability; however, it can be stored in pseudo-real time, making the architecture robust. Therefore, we decided to use a database to
store data rapidly, enabling the sensor nodes to endure the system without memory space constraints.
In summary, our proposed architecture differs from existing studies by focusing on robustness and versatility, employing a com-
bination of IPFS, MQTT, and database systems. This approach allows for the successful operation of the system for 100 continuous
hours with various sensor types and data formats. Additionally, our system addresses storage clearing in edge devices with limited
memory, ensuring robustness by preventing memory errors. The choice of MQTT as a lightweight message transfer protocol for IoT
edge devices is also a key feature of our architecture. Lastly, we opted for database storage over blockchain to facilitate rapid data
storage, enabling sensor nodes to endure the system without memory space constraints. As a result, it became feasible to implement a
system capable of continuously transmitting data at a scale many times larger than the storage capacity of IoT devices.
3. Core elements
Fig. 1 demonstrates the proposed system, which begins with the need for data storage in IoT devices. IoT devices lack memory space
despite the collection of large amounts of data. Furthermore, transferring data in real-time with numerous IoT edge devices is critical
for various applications, such as monitoring or emergency detection. The data storage system for IoT requires privacy protection and
data immutability, which IPFS achieves. By utilizing MQTT and a database, our proposed system can efciently overcome bandwidth
and computation constraints for communication, and obtain data at any given time. Moreover, MQTT sends the CID and metadata to
another device, while the database archives the message logs via MQTT.
In this section, we describe the characteristics and background of the core elements, highlighting the requirements and solutions of
each.
3.1. IPFS
IPFS is a peer-to-peer distributed le system developed to address the issues inherent in the current HTTP-based web [37]. The
centralized management of the HTTP-based web leads to latency, security, and privacy issues in central cloud storage [16,38]. IPFS can
provide a solution to these problems through its distributed le system. For example, when the Spanish government attempted to
censor the web in 2017, Catalans copied the content via IPFS to nd polling places [39].
When a device connects to IPFS and downloads a le, it immediately becomes shareable, with all participating nodes becoming part
of the le storage. This approach ensures that les are distributed without cost and security concerns. Moreover, IoT devices can share
data with low latency via IPFS [16,40].
IPFS utilizes content-based addressing. When a le is published to IPFS, a CID is generated based on an SHA-256 cryptographic
hash. Consequently, it is impossible to guess the input message from the hash, and the data remains secure. Users can access and
retrieve data correctly if they know the CID. Data is exchanged through the Libp2p protocol and stored locally in each node. CID serves
as the sole means of obtaining data. If the CID is unknown, the data remains inaccessible even if it is stored. Despite the large size of
uploaded data, a peer-to-peer le system is achievable through the 32-byte CID.
Even if the data is downloaded and deleted immediately, it will be saved in local storage at least once. Each node can delete
unnecessary les, known as garbage collection. Important les can be permanently stored using pin commands, which ensure that all
les except the pinned ones, are deleted during garbage collection. To address insufcient memory at a sensor node, it is necessary to
release the pin and perform garbage collection after saving the le to another node.
An IPFS private swarm is crucial for preventing data sharing with unauthorized parties. Data sharing can only occur within a
swarm. Users cannot access data, even with a valid CID, if they are not part of the IPFS private swarm. Sharing the swarm key and
registering the IPFS ID of other peers allows a device to join the IPFS private swarm.
The IPFS cluster is a fully distributed application for data backup [41]. IPFS clusters can communicate effectively when a cluster
secret, which is a 32-bit hex‑encoded passphrase, and an IPFS private swarm are identical. While pin-adding the hash from the sensor
node (different from the pin marking not to delete), the IPFS cluster copies the data and saves it in the local storage. The cluster peers
are automatically copied through the CRDT or RAFT mode. The IPFS cluster can replace the storage from the sensor node. If two or
more cluster peers are used, data is saved in a decentralized system, ensuring data persistence even if one cluster is lost.
IPFS uses a CID, guaranteeing secure data access. The IPFS private swarm ensures data privacy, while, a decentralized system
addresses the memory limitations of IoT devices. To achieve a completely decentralized system architecture, additional requirements
are needed for IPFS. As IPFS does not contain metadata and only addresses the CID, which is not understandable by users, and the
transfer of CID via IPFS is complex, our system requires an alternative CID transfer method called MQTT.
C. Lee et al.
Internet of Things 25 (2024) 101014
5
3.2. MQTT
MQTT is a lightweight open communication protocol that is benecial for machine-to-machine message communication over TCP/
IP [42,43]. The data carries a topic, message, and Quality of Service (QoS). When subscribing to a topic, the same message can be
automatically received when a new message is updated. Instead of direct communication between clients, brokers are required. Our
system conducted MQTT v5.0 with a Mosquitto broker in the network, rather than a cloud broker such as HiveMQ [44]. This
component is suitable for IoT communications [45].
A CID is a hash value that cannot be readily understood by users. Although an IPNS is user-friendly, it is not well-suited for le
systems with event-based messages. Our system recorded the metadata of the MQTT topic and the message described in JSON. Our
MQTT topic consisted of a function for implementation and a sensor for publishing data. Specically, the topic indicated performing a
specic function, and the subtopic indicated the type of sensor data. The message included the CID, date, time, and le name.
Additionally, we used QoS level 2 only once, which is more reliable and stable but has slower communication. The ID and password
needed to be authenticated, and only a specic IP was allowed to connect through the bind-address setting.
Sending a message with CID and metadata can be achieved using MQTT. The MQTT topic can accomplish a data hierarchy that
demonstrates a relationship between the les, which is not possible by using IPFS alone. However, this message is temporary. The user
needs additional elements to provide the CID and metadata at any given time. Therefore, our proposed system requires a database to
archive data.
3.3. Database
The proposed system incorporates a database to archive the content identiers and associated metadata for each dataset. This
approach ensures robustness, as the database can be utilized in various commands through SQL. We selected MariaDB as the database,
considering its open-source nature, availability for multiple users, lightweight structure, and high-speed performance, making it
suitable for resource-constrained devices.
The subtopic of MQTT serves as the name for each table, wherein the messages are stored. Each column comprises the CID, date
created, time created, publisher, pin-add status in the IPFS cluster, status of CID pin-release in the sensor nodes, le name, database
update time, and pin-add time. Access to specic tables is granted by providing different privileges through the ID and password for
each user.
Employing MariaDB as the database allows for efcient storage of the CID and metadata. Additionally, it facilitates the process of
nding, obtaining, and deleting the data les associated with the stored CID and metadata. The robustness of the proposed system is
enhanced by monitoring the status of the pin-add in the IPFS cluster, which aids in the storage clearing phase.
4. Architecture and implementation
Fig. 2 provides an overview of the proposed system architecture, which is based on IPFS, MQTT, and a database. This system
comprises sensors, sensor nodes, brokers, and data storage. Sensors generate data, which is processed and temporarily stored at the
sensor nodes. The brokers manage the data and CID transfer, and the generated data and CID are ultimately saved in data storage. By
Fig. 2. Overview of proposed system architecture.
C. Lee et al.
Internet of Things 25 (2024) 101014
6
employing this architecture, the data and metadata are stored in a decentralized and centralized manner, respectively, which enables
efcient data processing.
This section offers an overview of the system architecture and elaborates on the detailed algorithms of each device.
4.1. System requirement
In recent AI-driven applications, the most commonly used data for analysis is visual (1920 ×1080, 30fps, MP4, uncompressed): 0.6
MB per sec → 57.6 GB per 24 h) and audio (44.1 kHz, 160kbps, WAV, uncompressed): 0.16 MB per sec → 14.4 GB per 24 h) data.
Collecting this type of data continuously for 24 h requires a signicant amount of storage, as outlined below:
Generally, the storage capacity of commonly used IoT devices is at most 32 GB. Considering the storage capacity of such IoT
devices, it implies that a data management system within the IoT device, like the one proposed in this study, which includes data
disposal, is necessary to sustain data for more than 24 h.
To address this challenge, the considerations incorporated into our architecture are as follows:
1. An architecture for automatic data management and removal process within IoT devices after data transfer. Through this process,
developed system should collect, transmit, and store data exceeding the storage capacity of IoT devices.
2. An architecture that is resilient to system failures.
3. An architecture capable of resisting external attacks such as unauthorized access and packet interception.
4. An architecture for CIDs that should be systematically categorized using metadata, including topics, to ensure user-friendly access
to the desired CIDs, thus enabling the development of an efcient data acquisition system.
4.2. System architecture
As depicted in Fig. 2, the primary components of the system architecture are the edge device, hash manager, and IPFS cluster. The
edge device generates a le from the sensor data. The edge device communicates with the hash manager using the CID value through
MQTT after obtaining the IPFS publishing. The hash manager manages the CID and the metadata of the le and receives messages via
MQTT; the received message archives the CID and metadata in the database. One of the IPFS clusters subscribes to a message from the
hash manager and synchronizes with the le. The le is stored across multiple IPFS clusters.
Our system consists of the following three phases: (1) data collection, (2) storage clearing, and (3) data downloading.
The data collection phase involves collecting and transferring data from the edge device to the IPFS cluster, as illustrated in Fig. 3.
Edge devices with sensors provide data as les and obtain CIDs via IPFS. Subsequently, the CID and metadata of the le are organized
into messages, which are sent to the hash manager through the MQTT broker. The hash manager then inserts the CID and metadata into
the database and sends an MQTT message to one of the IPFS clusters. During the pin-adding process, IPFS clusters automatically copy
and store data through an IPFS private swarm.
The storage-clearing phase, shown in Fig. 4, ensures the sustainability of the edge device. During the preliminary experiment, the
edge device ran out of space if there was no storage-clearing process; thus, processes such as garbage collection and le deletion are
Fig. 3. Data collecting phase of proposed system architecture.
C. Lee et al.
Internet of Things 25 (2024) 101014
7
required for reusing storage. The IPFS cluster reports to the hash manager that the pin-add is complete. The hash manager then updates
the database. The edge device periodically accesses the database to receive the le and the CID is completely pin-added. The edge
device releases the pin status and performs garbage collection. When the CID pin is released, the column in the database is updated to
check whether the pin is released.
The data-downloading phase is demonstrated in Fig. 5. The downloading device is also placed on the IPFS private swarm. The
device receives the hash and le names using specic dates, times, and publishers via SQL statements. The le can be acquired by
subscribing via the IPFS. Pin-added data can be delivered from the IPFS cluster, and non-pin-added data can be delivered from the edge
device.
Fig. 4. Storage clearing phase of proposed system architecture.
Fig. 5. Data downloading phase of proposed system architecture.
C. Lee et al.
Internet of Things 25 (2024) 101014
8
4.3. Implementation of main components
In this section, we describe how our system is implemented with the following main components: edge device, hash manager, IPFS
cluster, and user.
As shown in Fig. 6, the owchart of the edge device is introduced. In the data collection phase, two threads are used. Data is
periodically collected every pre-dened period. Thread 2 creates a le and publishes it via the IPFS, which is also pinned at the edge
device, exposing the CID. The CID and metadata are sent to the hash manager in the form of a JSON via MQTT. In the storage-clearing
phase, the edge device periodically accesses the database and receives the CID, which is completely pinned. When placing the CID in a
queue, if more than a pre-dened number of CIDs (30 is the pre-dened number in this study) are stored, thread four is initiated. The
data le is removed, and the pin is released until the queue is empty. Garbage collection is then performed. Due to using the same
queue in each thread, we used a lock for safe interaction.
Fig. 7 presents the hash manager owchart, which subscribes to all MQTT topics. This process differs depending on the received
topic. If a message arrives from the edge device, the manager immediately stores it in the database and publishes the message to the
IPFS cluster. If a message comes from the IPFS cluster, the manager instantly updates the database to determine whether the pin has
been completely added.
Fig. 8 demonstrates the IPFS cluster owchart. The IPFS cluster subscribes to the message and then pin-adds the CID. If the pin-add
functions properly, the IPFS cluster updates the JSON message and sends it to the hash manager. If the pin-add does not function
correctly, which is dened by no action for a pre-dened period (10 s in this study), the IPFS cluster publishes the original message and
pin-releases the CID. This event occasionally occurs when the IPFS network is incorrect or the cluster is in the entire storage. Most cases
end within 10 s, which is why we dened 10 s as the pre-dened period.
Users can download several desired les using SQL statements. To provide a stressful situation for our implementation, the user
automatically downloads all the les in the database and accesses the desired database table. The nal data status is checked; if it does
not exist, it indicates that it is the rst time it is being downloaded. The data is then obtained from the rst row in the database. If there
is an existing status, the user receives data from the last row in the database. Users can obtain the CID and le names from this data and
record them in an array. By individually fetching the CID from the array, the user subscribes to the CID through the IPFS. The
downloaded raw le is renamed to the le name. Finally, the user records the status of the most recently downloaded data.
4.4. Fulllment of system requirements
This section describes how the system requirements stated in Section 4.1 are incorporated into our architecture.
Requirement 1: An architecture for automatic data management and removal process within IoT devices after data transfer.
The system requirements, paramount in the design of this architecture, have demanded meticulous consideration. To address these
requisites, a multitude of IoT devices are engaged in the continuous and real-time update of data pertaining to CID. The choice of a
Fig. 6. Flowchart of the edge device.
C. Lee et al.
Internet of Things 25 (2024) 101014
9
centralized database for CID data collection, management, and retrieval was made to reduce system latency and enhance its
robustness. Given that all processes are continuously ongoing and the data associated with a single CID is in constant ux, swift
comprehension of the data’s status is essential to expedite subsequent actions, thus reducing the nal process time. Databases
outperform blockchain-based technology in terms of speed and ease of updates. The fundamental data system is decentralized,
adopting IPFS, which simplies data transmission and storage tasks, resulting in streamlined algorithms.
Requirement 2: An architecture that is resilient to system failures.
Another advantage of this design is that IoT devices can respond to the data status associated with CIDs, ensuring continuous
operation even in the presence of errors. For instance, if an error occurs during data transfer from one device to another, the data
transfer process cannot be completed, and the database will not be updated. This phenomenon provides a basis for the originating
Fig. 7. Flowchart of the hash manager.
Fig. 8. Flowchart of the IPFS cluster.
C. Lee et al.
Internet of Things 25 (2024) 101014
10
device to reattempt the task. Subsequently, the transfer task is retried in the following step, enabling the device to overcome the failure
and maintain the system’s robustness. This functionality enables efcient management of storage capacity by conrming and deleting
data that is no longer needed.
Requirement 3: An architecture capable of resisting external attacks such as unauthorized access and packet interception.
The proposed system architecture is designed for residential environments, making considerations for privacy and data protection
essential. To address these concerns, the system incorporates the following components:
Firstly, the IPFS cluster utilized in this system operates as a private swarm, allowing access only to pre-authorized devices. This
additional authorization layer prevent unauthorized devices from accessing and exltrating data. Even in the event of a breach in the
centralized database containing all CIDs, a dual protection mechanism ensures that data cannot be retrieved without access to the
private swarm. Unauthorized devices are completely barred from contacting the system, restricting external access. This feature can
act as a safeguard, enabling users to block power to specic devices anytime to prevent data leakage and protect their privacy.
Furthermore, all data is encrypted through the IPFS cluster, making it impossible to obtain the desired data by attacking the storage
devices within the IPFS cluster or eavesdropping on data packets. IoT devices also perform a data deletion process upon successful
transmission to the IPFS cluster, ensuring no residual data remains on the devices. This greatly limits the data obtained even in the
event of a direct attack on the IoT devices from external sources.
Lastly, as depicted in Fig. 2, the separation of the route for CID transmission and data transmission ensures that the system is
designed to make it impossible to capture both CID and data simultaneously, even if one device is compromised.
Requirements 4: An architecture for CIDs that should be systematically categorized using metadata, including topics, to ensure user-
friendly access to the desired CIDs.
All CIDs are sorted in the database based on a variety of metadata, including topics, upload timestamp, data name, and the status of
data being uploaded to the system. Through this process, users can access desired data using automated programs. This system serves
as a cornerstone for improving user convenience and developing automated data acquisition and analysis systems.
5. Experiment
In this section, we present the experimental setup and results. The novelty of our work is demonstrated through a comparison with
related literature.
5.1. Experimental setup
In this research, a 100-hour continuous data acquisition experiment was conducted to assess the fulllment of the system re-
quirements outlined in Section 4.1. The hardware and network conguration are shown in Fig. 9. This experiment was designed to
monitor a home-like environment, as presented in Fig. 10. and Fig. 11. While all devices are located in one place, the system’s to-
pology, including equipment conguration and wired/wireless internet connections, closely matches the implementation in the
Fig. 9. Network and hardware system conguration for the experiment.
C. Lee et al.
Internet of Things 25 (2024) 101014
11
testbed. Therefore, it is considered adequate for validating the system’s functionality.
With the given hardware and network conguration, the experiment was executed for 100 h to verify the robustness and versatility
of the developed system. To achieve this goal, we created a burdensome environment by making frequent data transfers using eight
various sensors.
We used eight Raspberry-Pi devices as edge devices with a sensor. The specications of the sensors are presented in Tables 2,3,4,5.
We implemented various sensors for the Raspberry Pi Camera Module V2.1 for visual [46], Respeaker Mic Array 2.0 for audio [47],
ESP32 for Wi-Fi CSI data [48], and Airvisual Pro-for environmental data [49], including temperature, humidity, and air quality. Two
microphone sensors generated a WAV le every 8 s and 60 s. To generate visual data, the Pi-Cam generated H.264 les every 30 s. To
acquire the Wi-Fi CSI data, a CSV le was created when the data coming from the ESP32 was larger than a specic size. To obtain
Fig. 10. Example of system implementation.
Fig. 11. Actual experimental setup.
Table 2
Respeaker Mic array specication.
Specication Value
Name Respeaker Mic Array 2.0
No. of mic 4 (Output: 5ch)
Sensitivity 26 dBFS (Omnidirectional)
Diameter Φ70 mm
Max sample rate 48 kHz
Digital signal processor XMOS XVF-3000
Recording library PyAudio v0.2.11 with Python
C. Lee et al.
Internet of Things 25 (2024) 101014
12
environmental data, including temperature, humidity, CO2, and PM2.5, a JSON le was created every 30 min using information from
the network drive from Airvisual Pro-using the Samba protocol.
Data collection within the system is performed through separate threads of IoT devices by depositing data les into designated
folders. The system does not impose any constraints on data collection methods or data formats. For instance, in the case of sound data,
it is generated in the form of .wav les using a dedicated program authored in Python 3, leveraging the Pyaudio library.
The system automatically identies the presence of les within the designated folder and initiates their transmission through the
system. Upon completion of the transmission task, the system proceeds to delete the respective le. Data remains at the IPFS cluster
allocated to IoT devices even after the le deletion. When the system completes the data transfer process that includes conrmation of
data pinning completion on PCs within the cluster, IoT devices execute the un-pinning and garbage collection process.
The specications of the hardware devices are listed in Tables 6,7,8. We used the Raspberry-Pi 4 Model B as an edge device and
MariaDB database. We used a hash manager and MQTT broker as one hardware device: MacBook Pro (PC 2). MacBook Pro (PC 3) was
also used as an IPFS cluster. The user automatically downloads the data using a PC to check the le.
A ”go” implementation of IPFS, called kubo (go-ipfs), was used for each OS. Ipfs-cluster-ctl and ipfs-cluster-service were used for the
IPFS cluster. All the devices were included in the IPFS private swarm. We used an MQTT broker, Mosquitto, which is open-source and
easy to use. Paho-MQTT was used for MQTT to publish or subscribe to a message. The PyMySQL library was used to remotely access the
database server and execute the SQL statement. Detailed specications are listed in Table 9. All codes were implemented using Python.
5.2. Experimental results
A continuous operation experiment was conducted for 100 h. The total size of the data from the sensor nodes to the user via the IPFS
cluster was 356 GB. All the sensors were operated simultaneously to verify the robustness. The data period, le format, and sensor data
were varied. The detailed results are presented in Table 10. Furthermore, 103,103 les were created, and 103,056 les were received.
We suggested six cases in which losses can occur, as shown in Fig. 12. The rst case is the gap between the data when creating les.
The actual data period was slightly longer than 8 s because there was an unintended gap between each data le during the le-creating
process. The second case was data loss, which is dened by the le that was not created at the edge device. However, these two losses
are unrelated to data transfer and storage, meaning these two types of loss are not responsible for the proposed system architecture.
The third case is data publication loss, which occurs when the edge device cannot transfer or publish data through IPFS or MQTT after
the le is uploaded from the sensor. The fourth case is the updating DB loss owing to a bottleneck in MariaDB. The fth case is the
MQTT message loss owing to the bottleneck of MQTT. The last case is the IPFS data loss, where pin-add does not function owing to an
unknown bottleneck.
An additional operation experiment was conducted for 24 h using additional log-collecting functions with the database, the results
Table 3
Raspberry Pi Camera module specication.
Specication Value
Name Raspberry Pi Camera Module V2.1
Max supported resolution 3280 ×2464 pixels
Max frame rate capture 30 fps
Supported bus interfaces CSI-2
Recording library Picamera v1.13 with Python3
Table 4
ESP32 specication.
Specication Value
Name ESP32WROOM32D
Core ESP32-D0WD
Wi-Fi 802.11 b/g/n
Bluetooth Bluetooth V4.2 BR/EDR
Integrated SPI Flash 4MB
Recording library pySerial v3.5b0, NumPy v 1.19.5, with Python3
Table 5
AirVisual Pro-specication.
Specication Value
Name AirVisual Pro
Battery Rechargeable lithium Ion - 1900 mAH capacity
Wi-Fi 802.11b/g/n – 2.4 GHz
Operating temperature 32 to 104◦F (0 to 40 ◦C)
Sensing Temperature, Humidity, Co2, PM2.5
C. Lee et al.
Internet of Things 25 (2024) 101014
13
of which are presented in Table 11. The collected log includes the list of les created by the sensor node, the time when the data les
were created and published at the IPFS swarm, and the time when the pin-addition at the IPFS cluster was completed. The status of the
data les remained in the database; thus, the type of loss was determined.
Table 6
Raspberry Pi 4 Model B specication.
Specication Value
Name Raspberry Pi 4 Model B Rev1.1
CPU BCM2711 with 4 ARMv7 processor rev 3(v7l)
USB ports 2 USB 3.0 ports; 2 USB 2.0 ports.
Wi-Fi 802.11ac dual band
Camera 15 pin CSI
SD Card 32GB
OS Raspbian GNU/Linux 11 bullseye 32-bit, Debian
Table 7
PC 1 Specication.
Specication Value
Processor Intel(R) Core(TM) i7–7700 K CPU @ 4.20GHz
Memory 32GB RAM
Storage Samsung SSD 850 PRO 512GB
Wi-Fi Intel® dual band wireless-AC 7265
OS Windows 10 enterprise 20H2
Table 8
PC 2 / 3 specication.
Specication Value
Name MacBook Pro (2017)
Processor 3.5 GHz Dual-Core Intel Core i7
Memory 16GB 2133 MHz LPDDR3
Storage Macintosh HD 3 TB
Wi-Fi AirPort 802.11 a/b/g/n/ac
OS macOS Monterey version 12.3
Table 9
Software specication.
Name Role
Python 3.9.2 Language
kubo(go-ipfs) v0.13.0 Run IPFS and command-line of IPFS
ipfs-cluster-service v1.0.2 Run IPFS-cluster
ipfs-cluster-ctl v1.0.2 Command-line interface to manage IPFS cluster
Mosquitto v2.0.14 Broker of MQTT in MAC
Paho-MQTT v1.6.1 Publish/Subscribe via MQTT in Python
10.5.15-MariaDB-0+deb11u1 Database in Raspberry-pi
PyMySQL v1.0.2 Run SQL query in Python
Table 10
Results of nonstop operation experiment for 100 h.
Sensor File format Data period Average size of les # of created les # of received les Size of the received les
Audio 1 WAV 8 s 1.5 MB 44,687 44,665 67.0 GB
Audio 2 WAV 60 s 11.5 MB 5969 5964 68.6 GB
Wi-Fi CSI 1 CSV 44.25 s(Avg) 4 MB 8136 8132 32.5 GB
Wi-Fi CSI 2 CSV 35.24 s(Avg) 4 MB 10,216 10,212 40.8 GB
Wi-Fi CSI 3 CSV 32.52 s(Avg) 4 MB 11,069 11,066 44.2 GB
Wi-Fi CSI 4 CSV 32.63 s (Avg) 4 MB 11,033 11,029 44.1 GB
Visual H.264 30 s 5.4 MB (avg) 11,791 11,786 58.8 GB
Environment JSON 30 m 1.2 KB 201 201 241.2 KB
Total 103,103 103,056 356 GB
C. Lee et al.
Internet of Things 25 (2024) 101014
14
A detailed analysis was conducted as follows. Audio 1 was selected as the analysis target, which periodically created and published
a le of the same size every 8 s; the experiment was conducted for 86,404.6 s, which was calculated from the interval between the start
time of the rst le and the end time of the last le. The total time required for the data acquisition and transmission was determined to
be 85,992 s (10,749 les). With the aforementioned results, the loss time was calculated to be 412.6 s; the detailed results of the
analysis are presented in Fig. 13. The average gap was 0.028 s per le, and the total time was 300.6 s. This value, the rst case,
accounted for 72.9% of the total loss and 0.35% of the total experimental time. In the second case, missing data were not found. The
total data publishing loss and updating database loss in the third and fourth cases was 104 s (13 les), which accounted for 25.2% of
the total loss and 0.12% of the total experimental time. This loss occurred when the CID and metadata were not included in the
database. The total amount of MQTT message loss and IPFS data loss in the fth and sixth cases was 8 s (one le), which accounted for
1.94% of the total loss and 0.01% of the entire experimental time. This loss occurred when an IPFS cluster was not pin-added.
As shown in Fig. 14, the average lead-time can be calculated using the collected time log. The average lead time between data le
creation and data le publishing was 6.58 s. In addition, the average lead time between data le publishing and data le pin-addition
was 17.54 s. The total average lead time was 24.12 s. However, the les can be downloaded to determine whether they have been pin-
added. The non-pin-added les remained in the sensor nodes, so users could download the data from the sensor nodes. This result
demonstrated the possibility of semi-real-time data streaming and monitoring.
In summary, our experimental results showed that the proposed system was able to operate continuously for 100 h, with only a
small percentage of data loss. The majority of the data loss was attributed to the gap between data creation and le creation, while
other losses were due to data publication, updating DB, MQTT message, and IPFS data loss. The analysis also demonstrated that the
average lead time between data le creation and pin-addition was 24.12 s, enabling semi-real-time data streaming and monitoring.
Overall, these results demonstrate the robustness and versatility of the developed system.
Fig. 12. 6 showcases in which loss can occur.
Table 11
Results of additional operation experiment for 24 h.
Sensor File format Data period Average size of les # of created les # of received les Size of received les
Audio 1 WAV 8 s 1.5 MB 10,763 10,749 16.1 GB
Audio 2 WAV 30 s 5.6 MB 2879 2872 16.5 GB
Wi-Fi CSI 1 CSV 49.54 s (Avg) 4 MB 1744 1744 7.2 GB
Wi-Fi CSI 2 CSV 39.42 s (Avg) 4 MB 2192 2192 9.2 GB
Wi-Fi CSI 3 CSV 32.89 s (Avg) 4 MB 2632 2628 10.6 GB
Wi-Fi CSI 4 CSV 32.43 s (Avg) 4 MB 2668 2664 10.9 GB
Visual H.264 30 s 1.0 MB (Avg) 2868 2865 3.0 GB
Environment JSON 30 m 1.2 KB 48 48 60 KB
Total 25,794 25,761 73.5 GB
Fig. 13. Loss analysis: Audio 1.
C. Lee et al.
Internet of Things 25 (2024) 101014
15
5.3. Comparing the proposed system with relative studies
In Section 2, we compare literature considering decentralized data-sharing IoT domains using IPFS. Our proposed architectural
system satises the features presented in The most dominant method for storing metadata and CID is blockchain. However, blockchain
storage demands much more time to record the data CID and metadata with multiple IoT device participants. This is a critical issue for
implementation. A tradeoff exists between ensuring data stability and pseudo-real-time storage with high querying abilities. While
using a database does not guarantee data stability; however, it can be stored in pseudo-real time, making the architecture robust.
Therefore, we decided to use a database to store data rapidly, enabling the sensor nodes to endure the system without memory space
constraints.
In summary, our proposed architecture differs from existing studies by focusing on robustness and versatility, employing a com-
bination of IPFS, MQTT, and database systems. This approach allows for the successful operation of the system for 100 continuous
hours with various sensor types and data formats. Additionally, our system addresses storage clearing in edge devices with limited
memory, ensuring robustness by preventing memory errors. The choice of MQTT as a lightweight message transfer protocol for IoT
edge devices is also a key feature of our architecture. Lastly, we opted for database storage over blockchain to facilitate rapid data
storage, enabling sensor nodes to endure the system without memory space constraints. As a result, it became feasible to implement a
system capable of continuously transmitting data at a scale many times larger than the storage capacity of IoT devices.
Table 1. We implemented edge-device storage management in the storage clearing phase for robustness. A 100-hour experiment
proved the robustness of our system architecture. We applied multiple sensors including visual, audio, Wi-Fi CSI, and environmental
data, proving the versatility of the system. Due to the MQTT protocol, we can exchange CID and metadata with their topic. Using a
database helps store CID and metadata and creates a low-latency, robust architecture.
By comparing our proposed system with related studies, we can highlight the following advantages:
•Robustness: Our system demonstrated its ability to operate continuously for 100 h, handling data from multiple sensors and
ensuring the efcient management of storage at the edge-device level.
•Versatility: The implementation of various sensors, such as visual, audio, Wi-Fi CSI, and environmental data, showcases the sys-
tem’s adaptability and versatility in handling diverse types of data.
•Low-latency: The use of MQTT protocol allows for efcient exchange of CID and metadata with the MQTT topic, while employing a
database aids in managing CID and metadata storage, resulting in a low-latency and robust architecture.
Overall, the proposed system provides an effective and reliable solution for decentralized data-sharing in IoT domains using IPFS,
outperforming related studies in terms of robustness, versatility, and low-latency.
6. Conclusion
In this study, we proposed and implemented a hybrid architecture that combines decentralized data storage and centralized
management for IoT applications, focusing on its robustness and versatility. IPFS, a decentralized storage system, was employed, and
messages containing CID and metadata were exchanged via MQTT. A database was used to archive the CID and metadata for high
availability and monitoring the status of the data.
The architecture’s strength lies in its versatility and adaptability, addressing both the storage limitations of IoT devices and the
complexities of data management. This is achieved by streamlining data collection, regardless of the data’s size, format, or frequency.
Additionally, it lessens the dependence on centralized servers, improving data security and accessibility for more informed decision-
making processes. The hybrid architecture offers potential benets for various industry sectors by enhancing real-time communication
and collaboration, made possible by the centralized management of CID. As a promising development for IoT applications, this hybrid
architecture signies a step forward in handling the increasing demands of modern data-driven industries.
Fig. 14. Average lead time of data transferring.
C. Lee et al.
Internet of Things 25 (2024) 101014
16
CRediT authorship contribution
Chanhyuk Lee: Programming, experiment, writing – original draft Jisoo Kim: Design of algorithm and experiment, result analysis,
writing – review and editing Heedong Ko: Concept of architecture Byounghyun Yoo: Supervision, writing – review & editing.
Declaration of Competing Interest
The authors declare that they have no known competing nancial interests or personal relationships that could have appeared to
inuence the work reported in this paper.
Data availability
Data will be made available on request.
Acknowledgement
This work was supported by the Industrial Technology Innovation Program (20012462) funded by the Ministry of Trade, Industry
& Energy (MOTIE, Korea), the KIST under the Institutional Program (Grant No. 2E32281), and the National Research Foundation of
Korea (NRF) grant (NRF-2021R1A2C2093065) funded by the Korea government (MSIT).
References
[1] F. Grifths, M. Ooi, The fourth industrial revolution - Industry 4.0 and IoT [Trends in Future I&M], IEEE Instrum. Meas. Mag. 21 (2018) 29–43, https://doi.org/
10.1109/MIM.2018.8573590.
[2] S.S. Gill, M. Xu, C. Ottaviani, P. Patros, R. Bahsoon, A. Shaghaghi, M. Golec, V. Stankovski, H. Wu, A. Abraham, M. Singh, H. Mehta, S.K. Ghosh, T. Baker, A.
K. Parlikad, H. Lutyya, S.S. Kanhere, R. Sakellariou, S. Dustdar, O. Rana, I. Brandic, S. Uhlig, AI for next generation computing: Emerging trends and future
directions, Internet of Things 19 (2022) 100514, https://doi.org/10.1016/j.iot.2022.100514.
[3] J. Kim, H. Lee, S. Jeong, S.H. Ahn, Sound-based remote real-time multi-device operational monitoring system using a Convolutional Neural Network (CNN),
J. Manuf. Syst. 58 (2021) 431–441, https://doi.org/10.1016/j.jmsy.2020.12.020.
[4] N. Kikuchi, T. Fukuda, N. Yabuki, Future landscape visualization using a city digital twin: Integration of augmented reality and drones with implementation of
3D model-based occlusion handling, J. Comput. Des. Eng. 9 (2) (2022) 837–856, https://doi.org/10.1093/jcde/qwac032.
[5] Q. Gu, Q. Qu, Towards an Internet of Energy for smart and distributed generation: applications, strategies, and challenges, J. Comput. Des. Eng. 9 (5) (2022)
1789–1816, https://doi.org/10.1093/jcde/qwac087.
[6] E. Al Nuaimi, H. Al Neyadi, N. Mohamed, J. Al-Jaroodi, Applications of big data to smart cities, J. Internet Serv. Appl. 6 (2015) 25, https://doi.org/10.1186/
s13174-015-0041-5.
[7] S.M.H. Bamakan, N. Faregh, A. ZareRavasan, Di-ANFIS: an integrated blockchain–IoT–big data-enabled framework for evaluating service supply chain
performance, J. Comput. Des. Eng. 8 (2021) 676–690, https://doi.org/10.1093/jcde/qwab007.
[8] S. Noh, K. An, Reliable, robust, and comprehensive risk assessment framework for urban autonomous driving, J. Comput. Des. Eng. 9 (2022) 1680–1698,
https://doi.org/10.1093/jcde/qwac079.
[9] M.M. Mabkhot, A.M. Al-Ahmari, B. Salah, H. Alkhalefah, Requirements of the Smart Factory System: A Survey and Perspective, Machines 6 (2018) 23, https://
doi.org/10.3390/machines6020023.
[10] A. Papetti, F. Gregori, M. Pandol, M. Peruzzini, M. Germani, A method to improve workers’ well-being toward human-centered connected factories, J. Comput.
Des. Eng. 7 (2020) 630–643, https://doi.org/10.1093/jcde/qwaa047.
[11] H.T. Nguyen, G.H. Yu, N.R. Shin, G.J. Kwon, W.Y. Kwak, J.Y. Kim, Defective Product Classication System for Smart Factory Based on Deep Learning,
Electronics 10 (2021) 826, https://doi.org/10.3390/electronics10070826.
[12] H. Kim, H. Lee, J.S. Kim, S.H. Ahn, Image-based failure detection for material extrusion process using a convolutional neural network, Int. J. Adv. Manuf.
Technol. 111 (2020) 1291–1302, https://doi.org/10.1007/s00170-020-06201-0.
[13] M. Alaa, A.A. Zaidan, B.B. Zaidan, M. Talal, M.L.M. Kiah, A review of smart home applications based on Internet of Things, J. Netw. Comput. Appl. 97 (2017)
48–65, https://doi.org/10.1016/j.jnca.2017.08.017.
[14] R. Sokullu, M.A. Akkas
¸, E. Demir, IoT supported smart home for the elderly, Internet of Things 11 (2020) 100239, https://doi.org/10.1016/j.iot.2020.100239.
[15] S.S. Gill, S. Tuli, M. Xu, I. Singh, K.V. Singh, D. Lindsay, S. Tuli, D. Smirnova, M. Singh, U. Jain, H. Pervaiz, B. Sehgal, S.S. Kaila, S. Misra, M.S. Aslanpour,
H. Mehta, V. Stankovski, P. Garraghan, Transformative effects of IoT, Blockchain and Articial Intelligence on cloud computing: Evolution, vision, trends and
open challenges, Internet of Things 8 (2019) 100118, https://doi.org/10.1016/j.iot.2019.100118.
[16] S. Muralidharan, B. Yoo, H. Ko, Decentralized ME-Centric Framework—A Futuristic Architecture for Consumer IoT, IEEE Consum. Electron. Mag. 12 (2023)
39–50, https://doi.org/10.1109/MCE.2022.3151023.
[17] R. Thakore, R. Vaghashiya, C. Patel, N. Doshi, Blockchain - based IoT: A Survey, Procedia Comput. Sci. 155 (2019) 704–709, https://doi.org/10.1016/j.
procs.2019.08.101.
[18] N. Subramanian, A. Jeyaraj, Recent security challenges in cloud computing, Comput. Electr. Eng. 71 (2018) 28–42, https://doi.org/10.1016/j.
compeleceng.2018.06.006.
[19] M.S. Ali, K. Dolui, F. Antonelli, IoT data privacy via blockchains and IPFS. https://doi.org/10.1145/3131542.3131563.
[20] M.J.M. Chowdhury, A. Colman, M.A. Kabir, J. Han, P. Sarda, Blockchain Versus Database: A Critical Analysis. https://doi.org/10.1109/TrustCom/BigDataSE.
2018.00186.
[21] Benet, J. (2014). Ipfs-content addressed, versioned, p2p le system. arXiv preprint arXiv:1407.3561. https://doi.org/10.48550/arXiv.1407.3561.
[22] D. Di Francesco Maesa, P. Mori, Blockchain 3.0 applications survey, J. Parallel Distrib. Comput. 138 (2020) 99–114, https://doi.org/10.1016/j.
jpdc.2019.12.019.
[23] R. Li, T. Song, B. Mei, H. Li, X. Cheng, L. Sun, Blockchain for Large-Scale Internet of Things Data Storage and Protection, IEEE Trans. Serv. Comput. 12 (5) (2019)
762–771, https://doi.org/10.1109/TSC.2018.2853167.
[24] J. Lu, J. Shen, P. Vijayakumar, B.B. Gupta, Blockchain-Based Secure Data Storage Protocol for Sensors in the Industrial Internet of Things, IEEE Trans. Ind.
Electron. 18 (8) (2022) 5422–5431, https://doi.org/10.1109/TII.2021.3112601.
[25] R. Wang, W.T. Tsai, J. He, C. Liu, Q. Li, E. Deng, A Video Surveillance System Based on Permissioned Blockchains and Edge Computing. https://doi.org/10.
1109/BIGCOMP.2019.8679354.
C. Lee et al.
Internet of Things 25 (2024) 101014
17
[26] M. Sultana, A. Hossain, F. Laila, K.A. Taher, M.N. Islam, Towards developing a secure medical image sharing system based on zero trust principles and
blockchain technology, BMC Med. Inform. Decis. Mak. 20 (1) (2020) 1–10, https://doi.org/10.1186/s12911-020-01275-y.
[27] V. Ortega, J.F. Monserrat, Semantic distributed data for vehicular networks using the inter-planetary le system, Sensors 20 (2020) 6404, https://doi.org/
10.3390/s20226404.
[28] Y.E. Oktian, E.N. Witanto, S.G. Lee, A Conceptual Architecture in Decentralizing Computing, Storage, and Networking Aspect of IoT Infrastructure, IoT 2 (2021)
205–221, https://doi.org/10.3390/iot2020011.
[29] D.C. Nguyen, P.N. Pathirana, M. Ding, A.Seneviratne. BEdgeHealth, A Decentralized architecture for edge-based IoMT networks using blockchain, IEEE Internet
Things J. 8 (2021) 11743–11757, https://doi.org/10.1109/JIOT.2021.3058953.
[30] W. Li, M. He, W. Zhu, J. Zheng, in: A Study on Lightweight And Secure Edge Computing Based Blockchain, 2021, pp. 256–261. https://doi.org/10.1109/
ICSESS52187.2021.9522326.
[31] M. Shahjalal, M.M. Islam, M.M. Alam, Implementation of a secure LoRaWAN system for industrial internet of things integrated with IPFS and blockchain, IEEE
Sys. J. 16 (2022) 5455–5464, https://doi.org/10.1109/JSYST.2022.3174157.
[32] B. Dammak, M. Turki, S. Cheikhrouhou, M. Baklouti, R. Mars, A.Dhahbi. LoRaChainCare, An IoT architecture integrating blockchain and LoRa network for
personal health care data monitoring, Sensors 22 (2022) 1497, https://doi.org/10.3390/s22041497.
[33] IEEE Standard for Adoption of OpenFog Reference Architecture for Fog Computing, IEEE Std 1934-2018 (2018) 1–176. https://doi.org/10.1109/IEEESTD.2018.
8423800.
[34] V. Mani, M.M. Ghonge, N.K. Chaitanya, O. Pal, M. Sharma, S. Mohan, A. Ahmadian, A new blockchain and fog computing model for blood pressure medical
sensor data storage, Comput. Electr. Eng. 102 (2022) 108202, https://doi.org/10.1016/j.compeleceng.2022.108202.
[35] S.K. Dwivedi, R. Amin, S. Vollala, Smart contract and IPFS-based trustworthy secure data storage and device authentication scheme in fog computing
environment. Peer-to-Peer Netw, Appl 16 (2023) 1–21, https://doi.org/10.1007/s12083-022-01376-7.
[36] T. Hewa, A. Braeken, M. Liyanage, M. Ylianttila, Fog computing and blockchain-based security service architecture for 5G industrial IoT-enabled cloud
manufacturing, IEEE Trans. Ind. Electron. 18 (10) (2022) 7174–7185, https://doi.org/10.1109/TII.2022.3140792.
[37] kyledrake, HTTP is obsolete. It’s time for the Distributed Web. https://blog.neocities.org/blog/2015/09/08/its-time-for-the-distributed-web ,2015 (accessed 04
December 2023).
[38] S. Muralidharan, B. Yoo, H. Ko, Decentralized ME-Centric Framework—A Futuristic Architecture for Consumer IoT, IEEE Consum. Electron. Mag. 12 (3) (2022)
39–50, https://doi.org/10.1109/MCE.2022.3151023.
[39] M. Poblet, Distributed, privacy-enhancing technologies in the 2017 Catalan referendum on independence: New tactics and models of participatory democracy,
First Monday (2018), https://doi.org/10.5210/fm.v23i12.9402.
[40] S. Muralidharan, H. Ko, January). An InterPlanetary le system (IPFS) based IoT framework, 2019 IEEE international conference on consumer electronics (ICCE),
IEEE, 2019, pp. 1–2. https://doi.org/10.1109/ICCE.2019.8662002.
[41] IPFS Cluster. https://ipfscluster.io/documentation. (accessed 04 December 2023).
[42] U. Hunkeler, H.L. Truong, A. Stanford-Clark, in: January). MQTT-S—A publish/subscribe protocol for Wireless Sensor Networks, IEEE, 2008, pp. 791–798.
[43] B. Mishra, A. Kertesz, The use of MQTT in M2M and IoT systems: A survey, IEEE Access 8 (2020) 201071–201086, https://doi.org/10.1109/
ACCESS.2020.3035849.
[44] R.A. Light, Mosquitto: server and client implementation of the MQTT protocol, J. Open Source Softw. 2 (13) (2017) 265, https://doi.org/10.21105/joss.00265.
[45] I. Heđi, I. ˇ
Speh, A. ˇ
Sarabok, in: May). IoT network protocols comparison for the purpose of IoT constrained networks, IEEE, 2017, pp. 501–505.
[46] Raspberry Pi Camera Module 2, https://www.raspberrypi.com/products/camera-module-v2/ 2016 (accessed 04 December 2023).
[47] Seed Studio, ReSpeaker mic array v2.0, https://wiki.seeedstudio.com/ReSpeaker_Mic_Array_v2.0/ (accessed 04 December 2023).
[48] M. Atif, S. Muralidharan, H. Ko, B. Yoo, Wi-ESP—A tool for CSI-based device-free Wi-Fi sensing (DFWS), J. Comput. Des. Eng. 7 (5) (2020) 644–656, https://doi.
org/10.1093/jcde/qwaa048.
[49] IQAIR, AirVisual series product setup, https://www.iqair.com/air-quality-monitors/guides-manuals (accessed 04 December 2023).
C. Lee et al.
