A Blockchain-Driven Smart Broker for Data Quality Assurance of the Tagged Periodic IoT Data in Publisher-Subscriber Model

Abstract

The Publisher-Subscriber model of data exchange has been a popular method for many Internet-based applications, including the Internet of Things (IoT). A traditional PS system consists of publishers, subscribers, and a broker. The publishers create new data for a registered topic, and the data broker relays the data to the corresponding subscribers. This paper introduces a blockchain-based smart broker for the publisher-subscriber (PS) framework for the IoT network. As IoT data comes from devices operating in various environments, it may suffer from multiple challenges, such as hardware failures, connectivity issues, and external vulnerabilities, thereby impacting data quality in terms of accuracy and timeliness. It is important to monitor this data and inform subscribers about its quality. The proposed smart broker is composed of multiple smart contracts that continuously monitor the quality of the topic data by assessing its relationship with other related topics and its drift or delay in publishing intervals. It assigns a reputation score to each topic computed based on its quality and drifts, and it passes both the original data and the reputation score as a measure of quality to the subscriber. Furthermore, the smart broker can suggest substitute topics to subscribers when the requested topic data are unavailable or of very poor quality. The evaluation shows that a smart broker efficiently monitors the reputation of the topic data, and its efficiency increases notably when the data quality is worse. As the broker is run inside the blockchain, it automatically inherits the advantages of the blockchain, and the quality scoring is indisputable based on immutable data.

1. Introduction

The growing use of Internet of Things (IoT) data has brought the issue of data quality to the forefront of discussions surrounding IoT [1,2]. IoT applications, which rely on data generated by a multitude of sensors and devices, often contend with challenges related to the quality of this data [3,4]. IoT systems often use the Publisher-Subscriber model to exchange data between different stakeholders in the system [5]. In the current architecture [6,7], the data broker that manages the communication between IoT publishers and subscribers in the application network performs a dumb role as a relay. It gathers and organizes data coming from the IoT devices and passes them to the subscribers. However, IoT devices operate in challenging environments, making them susceptible to hardware failures, connectivity issues, and external vulnerabilities [8], which contribute to a drop in the quality of the data. Hardware failures and connectivity issues can disrupt the timely publishing of data, resulting in intervals that are delayed or irregular, ultimately affecting the trustworthiness of the information presented [9]. When the broker collects the data from devices that lack reliability, the quality of the data is compromised right from the initial stages [10]. Traditional data brokers focus on relaying the data between registered nodes—subscribers and publishers [11]. They have limited visibility, that is, understanding of the individual publishers’ (devices) performances at a given time.

Such brokers also do not have the analytical capabilities to compare the data streams with each other by design. The subscribers determine the quality or trust of the data upon receiving them at their end. In our proposed approach, the smart broker is given more power—monitoring and comparison. The smart broker already receives a range of data from various sources as real-time streams.

Obviously, there are no guaranteed relationships between such streams; however, over time, the smart broker can learn the bigger picture of an IoT system’s situation based on all the sensor data associated with it. Based on this, the smart broker can pass on a comment to the subscriber about the quality of the data. This avoids revealing actual data from unauthorized streams to a particular subscriber but still provides additional information.

In this paper, we deal with the quality of the data in terms of individual device performance. The quality issue may result from either the IoT end device’s own failures or due to an actual environmental change. It is assumed that an IoT sensor network is deployed in close proximity, monitoring the same target objects/space, and should agree with those other related devices [12]. This relationship of the devices due to deployment means one can make a group of devices that are closely related (directly or inversely), and this is exploited to characterize the quality of the data coming into a PS topic from a single device.

Usually, data brokers in the IoT do not recognize unreliable devices or publishers and detect the generation of unreliable data. This paper introduces a smart broker with a new blockchain-driven architecture designed to ensure acceptable data quality for subscribers. The new contributions are with regard to components of the smart broker, as follows:

(a)

An innovative topic drift monitoring module that keeps track of data publishing schedules.

(b)

A data quality assessment module. This module evaluates the quality of the data on the publisher’s topics. The smart broker identifies and flags unreliable topics through a peer assessment with other similar data streams in the same time frame. The blockchain guarantees that the quality assessment is impartial and timely.

We have chosen linear covariance calculations as a measure of the relationship between a predefined group of topics. This satisfies the needs of a smart broker; however, we have designed a flexible smart broker that can use better mechanisms for quality measurement.

(c)

A topic reputation scoring mechanism continuously assigns a score to each topic as a function of the quality and drift score of the topic data. This real-time score provides subscribers with current information on the topic, enabling them to make informed decisions based on the topic’s current reputation status.

(d)

The smart broker also acts as a recommender system for subscribers when the requested data are unavailable. Based on the subscriber’s original request, it offers the most reliable, relevant, and relatable data.

It is to be noted that the smart broker may be implemented without the blockchain, like a normal MQTT broker. But, without the blockchain, it loses the purpose of ensuring data integrity and impartiality in quality calculations. Hence, we propose an architecture that is suitable for blockchain. However, for the remainder of the paper, we assume that a publisher-subscriber broker can be deployed with blockchain as the back end [13,14] just like any traditional database.

The remainder of this article is organized as follows: Section 2 describes the related studies and limitations of the existing blockchain-based publisher subscriber, particularly in terms of providing quality-based data that subscribers can trust. Section 3 presents a new blockchain-based PS model with a smart broker. The detailed design of the smart broker is given in Section 4. The implementation details and the performance evaluation are discussed in Section 5. Section 6 highlights the advantages of the smart broker, along with its limitations and the additional study needed to further improve its efficiency. Finally, Section 7 concludes the article.

2. Related Works

This section discusses the related study regarding limitations in the existing PS models and the blockchain-based PS models in terms of guaranteeing the delivery of high-quality data that subscribers can fully trust.

2.1. Existing Publisher-Subscriber Approach

2.1.1. Centralized Architecture

The quality of IoT data is significantly influenced by the centralized ownership of data brokers [15]. Centralized nature poses inherent risks, as unauthorized access could compromise data integrity [16]. Tampering incidents pose a significant threat [17], as any alterations to the collected data can result in the dissemination of poor-quality data to the subscribers [18]. A decentralized architecture would provide enhanced security, making it more challenging to tamper with the data before it is sent to the subscriber [19].

The centralized architecture of the data broker preceding data transmission to the IoT platform is susceptible to various vulnerabilities, including data tampering, which can compromise data quality [20]. Past studies have sought to enhance the security of this storage by integrating it with blockchain networks [21,22,23,24,25,26,27,28]. The smart broker is the best alternative solution to this, as it already receives all the data in real time and can make opinions about the data relative to other data in real time without worrying about storing any information for a long period of time.

2.1.2. Scalability and Efficiency Issues

PS brokers for IoT data can face significant scalability issues, primarily due to the huge volume and velocity of data generated by numerous connected devices. These models often struggle to process and transmit data in real time, creating performance bottlenecks as the number of devices increases [21,29]. Blockchain’s decentralized and immutable ledger has been shown to efficiently handle large-scale IoT data by distributing the workload across a network of nodes, thus preventing bottlenecks and enhancing system resilience and performance. For example, the REEDS system (Revocable End-to-End Encrypted Message Distribution System) proposed in [30] utilizes blockchain’s decentralized nature to provide secure and efficient data storage and processing, ensuring data integrity and reducing latency through automated transactions and data verification via smart contracts. Other works mentioned [31] focus on implementing blockchain technology for various IoT-based applications to improve the security and scalability issues of IoT. Although we do not focus on the scalability issues in this paper, previous studies suggest that the scalability-related challenges are the same whether blockchain is used or not.

2.1.3. Quality Issue

The data quality can be measured from various points of view in the IoT [32], but the most fundamental of those is the intrinsic data quality, which measures the accuracy and trustworthiness [33]. Our proposed smart broker measures data quality by considering only the incoming publisher data as a big data set. This incorporates various aspects of ISO 8000 specifications, such as timeliness and reducing redundancies [34]. However, it also ignores the subscriber’s characteristics and desires. This is due to the basic nature of publisher-subscriber architecture, which only focuses on the fast distribution of incoming publisher data.

2.2. Blockchain-Based Publisher Subscribers

The study presented in [5] introduces ‘Pub-SubMCS’, a privacy-preserving decentralized framework for MCS systems. Using a publish-subscribe model enables data sharing, allowing subscribers to match existing data requests or create new tasks with specific requirements. While the pub–sub-model conserves resources, it exacerbates sensing issues, addressed by Pub-SubMCS through smart contract-based access control. This ensures the early identification and penalization of malicious workers. Data privacy and validation are ensured through blockchain by employing data transformation techniques, such as normalization, and utilizing the Pearson correlation coefficient measure to assess similarity in collected sensor data. However, the Pearson correlation alone may not suffice for assessing similarity in collected sensor network data, particularly in real-world scenarios where identical data types may be unavailable. In such cases, the inclusion of sensor associations become crucial for selecting alternative data sources. This approach ensures a more comprehensive measure of similarity, accommodating situations where the exact data sought may not be present.

Trinity [15] pioneered the integration of the Publisher-Subscriber model with blockchain. However, it presumed data accuracy without addressing the challenge of storing substantial volumes on the blockchain. Unlike Trinity’s decentralized approach, which uses multiple brokers, this research sets the broker directly on blockchain technology, offering a more streamlined and integrated solution.

Other recent blockchain-based publisher-subscriber models presented in [35,36], [13,37,38], and [14,39,40] mainly focused on authentication, data privacy, and improving the quality of service. However, the quality assessment of the data itself remains unaddressed. Another critical aspect of the smart broker with blockchain is that the blockchain needs to be permissioned. It does not need currency, and the consensus mechanism can be proof-of-work or similar. To be most effective, permissioned peer publishers’ static information, for example, identification details, can be verified in the real world, at least initially.

2.3. Trust vs. Quality

Establishing trust between IoT users and data brokers relies significantly on data quality, which is a crucial factor often overlooked in current research. Quality is assumed to be a subset of trust, implying that if the data are of good quality, a certain degree of trust builds between the IoT users [41,42]. IoT end-users, lacking the means to independently verify data quality, must rely on the trustworthiness of brokers. While existing studies prioritize privacy and security concerns [43], as demonstrated in the study proposed by [44,45], the importance of data quality in building trust between IoT users and brokers is often neglected.

2.4. Recommendation Strategies

In the IoT environment, IoT devices often face resource limitations and increased vulnerability to malicious attacks. Therefore, many trust-based recommendation systems, such as TRec [46], have also been introduced. It is a lightweight trust inference model for service-centric IoT that enhances trust-based recommendation in the SIoT by employing a weighted centrality metric and trust path section algorithm to establish trust. It integrates factors like rating, direct trust, and indirect trust into a matrix factorization model to enhance the accuracy of predicting ratings. Another technique presented in [47], integrates collaborative and content-based filtering along with AI technology to enhance cyber-physical system security. This approach captures interaction data between Mashup and Web services, extracting semantic similarities. Implemented in a deep neural network, it predicts Mashup service ratings, improving security and service quality in CPSs.

The recommendation strategy proposed in [48] is COSS, the first Content-based Subscription Service designed specifically for IoT. With inherent multitenant support and accessible REST APIs, COSS tackles the challenge of Balanced Rule Engine Partitioning. It addresses the NP hardness of dynamically adapting message distribution based on workload history, ensuring scalability and high performance for content-based subscriptions in IoT applications. The recommendation strategy proposed in [49] involves deploying a blockchain-IoT-based model to enhance the logistic process. Other strategies proposed in [50,51,52] are efficient in providing recommendations based on similarity or user preference.

3. Proposed Architecture Overview

3.1. Request–Response Model

In this study, we define a new request–response model that consists of a smart broker designed to manage subscriber requests for topics and deliver them with a quality score (see Figure 1). There are two types of requests in this model, as follows:

• Direct Request–Response: Like traditional PS models, the subscriber asks for data for a topic (τ), and the smart broker responds with the data. Along with the data, the broker also sends a quality score q_τ [0, 1]. It is expected that the broker, if based on a blockchain, will provide reliable, unbiased, and quality information.
• Substitution Request–Response: A special case arises in this model when the requested data are not present at the current time. As the broker is smart and based on blockchain, it can recommend some other topics to the subscriber that are similar to the topic originally requested. These substitution recommendations may also be given if the quality of the data for the q_τ drops dramatically. It is then up to the subscriber to decide on a recommended topic. Once the subscriber chooses a substitute topic τ′, further communication follows the direct request–response as before.

Figure 1. The request–response model consists of a smart broker, publishers, and subscribers.

Figure 1. The request–response model consists of a smart broker, publishers, and subscribers.

To achieve this model in a PS application, several new procedures have been developed, including protocols for publishers to join the PS system, assessment of the data quality, and running the processes from within a blockchain.

3.2. Proposed System Architecture: Smart Broker

In this new blockchain-driven PS architecture, the smart broker has the following new capabilities compared to a traditional PS broker:

• Calculating the quality of data for the publishers. This is typically performed for individual topics based on various parameters, such as relationship with other topics and timeliness.
• Preparing a list of recommended topics based on the metadata of the topics in case a particular topic is not available.

The blockchain-driven model consists of several modules communicating with each other as depicted in Figure 2:

(1)

Publisher-topic registration serves as the first step for any new incoming publisher (IoT device) data within the smart broker. It enables the registration of topics by analyzing the presence of essential tags. Additionally, topics are manually grouped based on their correlation to one another.

(2)

The Topic Data Quality Assessment Module (TDQAM) assesses the reliability of registered publisher IoT data by checking its quality and promptly acting to flag publishers providing poor-quality data. The publisher’s data that has gone through reliability checks is granted access to the blockchain-based storage.

(3)

The blockchain-based Data Storage Module (DSM) is designed to store data from all the modules, including data that have passed the assessment checks, accompanied by its corresponding quality score.

(4)

Topic Drift Monitoring (TDM) monitors the publishing intervals of the publishers by detecting changes in the patterns of these intervals over time. It then transmits this information to the blockchain-based Topic Reputation Scoring (TRS) model.

(5)

The TRS continuously monitors the publisher’s reputation by using assessments from both TDQAM and TDM, providing reputation scores to each publisher. The Subscriber Request Assessment Module (SRAM) uses these reputation scores to prepare and send a publisher’s reputation score when a subscriber requests data from that publisher.

(6)

The SRAM manages IoT data requests from subscribers. It accepts incoming requests and delivers the requested data, along with its quality score, to the subscriber. It may also recommend substitute topics.

TDQAM, TDM, and TRS operate at regular time gaps of λ and w.

Figure 2. A detailed overview of the smart broker.

Figure 2. A detailed overview of the smart broker.

3.3. Assumptions

This paper’s contributions make the assumptions as follows:

• Tagged Data: It is assumed that publishers create a limited number of alphanumeric tags accurately for each topic they publish. This framework relies on these tags to identify potential substitutes.
• Periodic Data: The data streams are periodic, that is, they are expected to send data at regular intervals. Periodicity assists in identifying delays in publishing intervals by establishing the expected timing for publication data and identifying deviations from these intervals.
• Manual data stream grouping: To establish quality, the proposed methods rely on sensor associations based on their own proximity and the proximity of the observed environment. It is assumed that this association is performed manually as part of the topic registration, and a group has a minimum of three topics. Under normal circumstances, the blockchain can keep track of and confirm this relationship continuously.

For this paper, we consider that there is a fixed window of time w_ij, for which the time series in a group would follow a relationship (direct or inverse) at a degree of v_ij. This is a common feature in many IoT application data that track a periodic system. In this paper, a weather data set is used that exhibits this property [53]. However, in other practical applications, the windows themselves could vary over a period of time, and the expected relationship scores would also be different for those time periods. Such possibilities are not the focus of this paper, where we emphasize the smart broker’s structure and ability to detect quality and recommend substitutions.

• Fixed Location: The IoT devices are assumed to be in fixed positions. These positions may be geographic or referential, such as in a building or factory. In other words, they are non-mobile by nature. Any change in the location needs to be updated in the blockchain and the pairings.

4. Design

The proposed architecture consists of two parallel running sections—mostly publisher-end modules that run according to data arriving at the broker from publishers and subscriber-end modules that accept and respond to subscribers’ requests. The most common and recurring system parameters considered in this paper are listed in

Table 1. Parameters/Symbol Table.

Symbols	Meaning
$\tau$	A topic in the PS system
$\delta$	Expected publishing interval
$g$	A tag for the topic
$D_{\tau }$	Drifting sore Performance indicator of the topic
$r_{\tau }$	Reputation of the topic$\tau$
$q_{\tau }$	The quality of the sensor data related to the topic$\tau$
s	Similarity score
t	Current time
$v_{ij}$	Expected relationship between the paired topics$\{{\tau }_i,{\tau }_j\}$
$a_{ij}$	Association coefficient between the paired topics$\left\{{\tau }_i,{\tau }_j\right\}$
$w_{ij}$	Time window for calculating quality for topics i and j
$\mu$	Tolerance level of drift
λ	Time window for calculating drift for a single topic

.

4.1. Publisher-Topic Joining

4.1.1. Overview

The publisher establishes a connection with the blockchain network (smart broker) and then starts to register new topics. Each topic $\tau$ corresponds to a sensor that the publisher $p$ is responsible for. The whole set of topics in the smart broker belonging to all publishers is as follows:

$$\Gamma =\{{\tau }_1,{\tau }_1,\cdots ,{\tau }_m\}$$

(1)

where τ_i = {y_i, G_i}. Equation (1) defines $\Gamma$ as the sets of topics in the blockchain. Each τ_i contains tags that provide static information about the topic data. The set of tags is denoted as follows:

$$G=\left\{l,\delta \right\} \bigcup \left\{g_1, g_2,\dots ,g_n\right\}$$

(2)

Every G contains two specific tags required for the acceptance of the topic registration, along with other generic tags:

• Location Tag (l): The location of the sensors collecting data related to τ_i is essential for SRAM to provide recommendations to subscribers. SRAM can recommend topics based on data from sensors that are closely related to each other.
• Publishing interval Tag ($\delta )$:The publishing interval of the data related to the τ_i denotes the frequency or timing at which the data are published. The publishing interval is used by the TDM to calculate the publishing interval monitoring score, which will ultimately be used to calculate the topic’s reputation score in the smart broker.
• Other generic tags, such as sensor type, key timestamps, keywords, and measurement units, provide additional information and descriptions about the topic. There is both an upper and lower limit to the number of tags for a topic. This is to ensure that the recommendation process has sufficient data and, at the same time, is not biased toward any topic. Tags must also be chosen from a preset list of tags.

4.1.2. Topic Registration Process

The exact topic registration process will be different for smart brokers, depending on the data required for the specific quality assessment and recommendation technique used. But they would largely follow the following steps:

• Upon receiving the publisher’s topic joining request, the smart broker first verifies the presence of essential tags in the topic.
• Then, the manual data grouping of the topics takes place. It relies on the actual relationship that exists among the data streams. The correlation matrix (shown in Equation (3)) represents the actual relationship between the paired topics $\{{\tau }_i, {\tau }_j\}$. Each pair of correlated topics has a predefined expected correlation value ${(v}_{ij})$ indicating the nature of their relationship within a range of −1 to 1, where 1 signifies a perfectly direct relationship, 0 denotes no relationship, and −1 represents a perfectly inverse relationship. These values are mapped to a range of 0 and 1 before storage in the database, where 1 indicates a perfect direct or indirect relationship, and 0 indicates no relationship. By default, $v_{ij}=0$, indicating that there is no relation at all. Typically, the smart broker will ignore such values and only consider topic pairs where $v_{ij}\ne 0$. This correlation matrix is used by the TDQAM to conduct quality checks on the topic data.

  $$C=\left[\begin{array}{ccccc}& {\tau }_1& {\tau }_2& \dots & {\tau }_m\\ {\tau }_1& \left\{{\lambda }_1,1\right\}& \left\{W_{12},V_{12}\right\}& \dots & \left\{W_{1m},V_{1m}\right\}\\ {\tau }_2& \left\{W_{21},V_{21}\right\}& \left\{{\lambda }_2,1\right\}& \dots & \left\{W_{2m},V_{2m}\right\}\\ ⋮& ⋮& ⋮& \ddots & ⋮\\ {\tau }_m& \left\{W_{m1},V_{m1}\right\}& \left\{W_{m2},V_{m2}\right\}& \dots & \left\{{\lambda }_m,1\right\}\end{array}\right]$$

  (3)

  where $W_{ij}=W_{ji}=\left\{w_{ij}^0,w_{ij}^1,w_{ij}^2 \dots w_{ij}^k\right\}$ is the reputation time window set corresponding to the topics τ_i and τ_j. Each $w_{ij}^k\in W_{ij}$ has a corresponding $v_{ij}^k$, which is the expected correlation value in that window. As the time series is periodic, the set of windows $W_{21}$ will keep repeating infinitely. Additionally, λ is stored for the topic itself, which is another window for resetting drift scores. Typically, ${\lambda }_{\tau }\le \underset{iϵ\Gamma }{\min }{w}_{i\tau }$ to ensure that the drift score is calculated quickly enough for reputation scoring.
• Finally, upon successful registration, the smart broker assigns a unique identity to the publisher topic and stores the identity in the blockchain. Upon successful registration, the publisher can start sending IoT data related to the topic.

4.2. Topic Drift Monitoring

This module penalizes the reputation of a topic for delays in data arrival. The TDM keeps track of how well data publishing stays on schedule. Initially, publishers specify their intended publication intervals $\left(\delta \right)$ for each topic. The TDM then monitors when each registered topic’s data are published to ensure that it aligns with the intended interval $\left(\delta \right)$. Let us assume that $t_u^{\lambda }$ is the time at which the u^th data point has arrived, $t_0^{\lambda }$ denotes the reference time from when the drift is measured, which is the beginning of the drift time window λ > δ. The u^th data for τ must arrive at $t_0^{\lambda }+u\delta$ time, that is,

$$t_u^{\lambda }=t_0^{\lambda }+u\delta$$

(4)

where $\lambda ={\lambda }_{\tau },$ from C in Equation (3). Based on this, the drifting score $\left(D_{\tau }\right)$ is created as shown in Equation (12).

$$D_{\tau }=\left\{\begin{array}{c}\left|t_u^{\lambda }-(t_0^{\lambda }+u\delta )\right|>\mu \hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}0\\ \left|t_u^{\lambda }-(t_0^{\lambda }+u\delta )\right|=0\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}1\\ Otherwise\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}1-\frac{\left|t_u^{\lambda }-(t_0^{\lambda }+u\delta )\right|}{\mu }\end{array}\right.$$

(5)

where tolerance $\mu \ge \delta$. If in Equation (12), both sides are equal, that is, the data are arriving at the correct time, the $D_{\tau }=1$, that is, when everything is perfect since $t_0^{\lambda }$. If the delay in the data is more than $\mathsf{\mu }$, then the $D_{\tau }=0$, which means that the data are no longer there and reliability with respect to time is zero. If $0<\left|t_u^{\lambda }-(t_0^{\lambda }+u\delta )\right|<\mu$, then, the last part returns a score between 0 and 1. This drifting score, ${\mathrm{D}}_{\mathsf{\tau }}$, is used by the TRS further to calculate the overall topic reputation score. $\mathrm{D}$ is calculated at every interval of δ.

The drift in the topic can cause some unwanted problems, as it could occur that in a particular window, there is not enough data to calculate the quality. In such cases, the D would already become 0, and the quality calculations would be impacted. The value of µ should be set in a way such that the system quickly recognizes that excessive drift is occurring, resulting in difficulties with quality calculations as discussed below.

4.3. Topic Data Quality Assessment Module

The quality assessment method can be both supervised and unsupervised and relies on sensor association, requiring IoT data from at least three correlated time series. The TQDAM must satisfy the following characteristics at the minimum:

• It needs to establish a reference mechanism to measure the correctness of the currently incoming data. This can be performed in two ways:
  • Absolute reference is where the user creates a set of static reference values, and quality is a measurement of deviation from these reference points. This can take the form of self-assessment with its own historical reference value. However, many sensor data may have randomness, meaning matching with its own history or fixed reference may be difficult.
  • Relative reference is peer assessment at the current time. If the IoT systems generate a continuous stream of data, then we get a multivariate time series. This mechanism would aim to establish the deviation of one topic’s data compared to other topics. In this paper, we focus on peer assessment using unsupervised methods.
• A mechanism that only considers some of the latest incoming data points, that is, upgrading the quality score whenever the latest window of data are available. In the case of supervised mechanisms, methods of determining time windows may be different from those used in the paper.
• The quality score should be on the same scale. In this paper, we aim to calculate everything as a real number between 0 (worst quality) and 1 (best quality). The scoring should also be uniform across all the topics.
• The most important factor is to ensure that each data stream is evaluated in isolation while being compared to others, that is, the quality score calculation for each data stream must be calculated to reflect its own quality only.

Normalized Group-Specific Quality Assessment

In this paper, we consider a covariance and co-relation-based peer assessment method to obtain a Normalized Group Specific Quality Assessment, that is, an assessment of the reliability of a topic with respect to other topics in the same group. Let us consider three correlated topics, namely, τ₁ = {$y_1$, G}, τ₂ = {$y_2$, G}, and τ₃ = {$y_3$, G}, and R = {τ₁, τ₂, τ₃} obtained from the correlation matrix (C), which are grouped together, where $y_1$, $y_2$, and $y_3$ represent the data associated with each respective topic.

If the publishing intervals δ of $y_1$, $y_2$, and $y_3$ are not the same, interpolation in data is required for each pair in the group. This ensures that all data streams in R are synchronized or have the same number of points, especially if there is more data in one stream compared to the others. The quality assessment begins by applying covariance analysis on $y_1$, $y_2$, and $y_3$ for a corresponding window w (see Equations (4)–(6)).

$$cov(y_1,y_2,w_{12})=\frac{1}{w-1}{\sum }_{d=1}^{w_{12}}({y_1}_d-{\overline{\mathrm{y}}}_1) ({y_2}_d-\overline{y_2})$$

(6)

$$cov(y_1,y_3,w_{13})=\frac{1}{w-1}{\sum }_{d=1}^{w_{13}}({y_1}_d-\overline{y_1}) ({y_3}_d-\overline{y_3})$$

(7)

$$cov(y_2,y_3,w_{23})=\frac{1}{w-1}{\sum }_{d=1}^{w_{23}}({y_2}_d-\overline{y_2}) ({y_3}_d-\overline{y_3})$$

(8)

As the smart broker is only interested in relationship nature, that is, direct or inverse, the correlation is calculated and normalized as follows:

$$a\left({\tau }_1,{\tau }_2,w_{12}\right)=\left(1+\frac{\left(cov\left(y_1,y_2,w_{12}\right)\right)}{\left({\sigma }_{y_1}·{\sigma }_{y_2}\right)}\right)/2$$

(9)

$$a\left({\tau }_1,{\tau }_3,w_{13}\right)=\left(1+\frac{\left(cov\left(y_1,y_3,w_{13}\right)\right)}{\left({\sigma }_{y_1}·{\sigma }_{y_3}\right)}\right)/2$$

(10)

$$\left({\tau }_2,{\tau }_3,w_{23}\right)=\left(1+\frac{\left(cov\left(y_2,y_3,w_{23}\right)\right)}{\left({\sigma }_{y_2}·{\sigma }_{y_3}\right)}\right)/2$$

(11)

Equations (7)–(9) provide the association coefficients $a\left({\tau }_1,{\tau }_2\right)$, $a\left({\tau }_1,{\tau }_3\right),$ and $a\left({\tau }_2,{\tau }_3\right),$ respectively, within a range of 0 to 1 for the grouped topics R = {${\tau }_1$, ${\tau }_2$, ${\tau }_3$}, respectively. These coefficients measure the strength of the association between the respective pairs of topics. The actual association coefficients $a\left({\tau }_i,{\tau }_j\right)$ and the expected association $v_{ij}$ are used to calculate the quality of the topic ${\tau }_1$ as follows:

$$q\left({\tau }_i\right)=\frac{{\prod }_{i\ne j\bigwedge \left(i,j\right)\hspace{0.17em}\in \hspace{0.17em}R}\left(1-\left|a\left({\tau }_i,{\tau }_j\right)-v_{ij}\right|\right)}{{\left(\mathit{max}\left\{\left(1-\left|a\left({\tau }_1,{\tau }_2\right)-v_{12}\right|\right),\left(1-\left|a\left({\tau }_2,{\tau }_3\right)-v_{23}\right|\right),\left(1-\left|a\left({\tau }_1,{\tau }_3\right)-v_{13}\right|\right)\right\}\right)}^2}$$

(12)

Equation (12) defines the quality of a given topic, for example, $q\left({\tau }_1\right)$, by examining its relationship with other topics, for example, ${\tau }_2$ and ${\tau }_3$ using their expected correlation ($v_{ij})$ and the calculated association coefficients $\left(a_{ij}\right)$. Figure 3 shows the topic relationships $R=\{{\tau }_1,{\tau }_2,{\tau }_3\}$. For a group of three topics, the relationship is expected to be at $v_{ij}$ for window $w_{ij}$ for the respective pairs of topics. The quality calculated is the product of the ratio of the correlation difference for the relationships $\left(1-\left|a\left({\tau }_i,{\tau }_j\right)-v_{ij}\right|\right)$ that contain the topic and the lowest correlation difference in the group R. It is expected that the lowest correlation difference signifies the relationship of topics that still holds steady, that is, ${\tau }_2$ and ${\tau }_3$. The other two relationships change as ${\tau }_1$ are getting corrupted values, which throws the correlation off track. Note that the quality is calculated based on the difference between the expected and current correlations $\left(1-\left|a\left({\tau }_i,{\tau }_j\right)-v_{ij}\right|\right)$ and not the correlations themselves.

The resulting value of $q\left({\tau }_i\right)$ falls within the range of (0, 1), where 1 denotes perfect quality, indicating high accuracy in the data, while 0 signifies poor quality. This can be generalized to:

$$q\left({\tau }_i\right)=\frac{{\prod }_{i\ne j\bigwedge \left(i,j\right)\hspace{0.17em}ϵ\hspace{0.17em}R}\left(1-\left|a\left({\tau }_i,{\tau }_j\right)-v_{ij}\right|\right)}{{\left(\underset{k,j\in \mathit{R}\wedge \mathit{k}\ne j}{\mathit{max}}\left\{\left(1-\left|a\left({\tau }_k,{\tau }_j\right)-v_{kj}\right|\right)\right\}\right)}^{\left|R\right|-1}}$$

(13)

The denominator is raised to $\left|R\right|-1$, where the $\left|R\right|$ is the number of topics in the group R. However, making a large group could negatively impact the quality score for its constituent topics compared to a smaller group. Hence, the smart broker should aim to use a static group size. In this paper, for ${\tau }_1$ considers only two additional topics ${\tau }_2$ and ${\tau }_3$ calculating topic using Equation (12), where $\left|a\left({\tau }_1,{\tau }_2\right)-v_{12}\right|$ and $\left|a\left({\tau }_1,{\tau }_3\right)-v_{13}\right|$ are the minimum in the group, keeping its size to 3.

For every $w_{ij}$, the TDQAM calculates the new association coefficients based on the last completed window of all w ∈ R and stores them in the ledger. At any point in time for a group, the corresponding quality can be calculated based on the last available association scores, that is, Q = {q₁, q₂, q₃}. The final score for quality is then normalized within the group to obtain the Normalized Group Specific Quality for each quality score in Q.

4.4. Topic Reputation Scoring

The TRS keeps monitoring the reputation score of the topic by using Equations (10) and (12). To calculate the reputation score, a combination of the TDM score and the TDQAM score of the topic is used (see Equation (14)). Both metrics are normalized to the range of 0 to 1.

Let $r_{\tau }$ denote the reputation score of the topic τ, as shown in Equation (13), and the $\alpha$ and $\beta$ are the weights assigned to $D_{\tau }$ and $q_{\tau }$ respectively. The scoring formula can be expressed as follows:

$$r_{\tau }=\alpha .D_{\tau }+\beta ·q_{\tau }$$

(14)

The weights $\alpha \mathrm{a}\mathrm{n}\mathrm{d} \beta$ assigned to $D_{\tau }$ and $q_{\tau }$ adjust their importance or priority under different IoT scenarios. Equation (15) further normalizes the reputation score $r_{\tau }$ in the range of 0 to 1.

$$r_{\tau }=\frac{\alpha .D_{\tau }+\beta .q_{\tau }}{\alpha +\beta }$$

(15)

where $\alpha ,\beta >0$. The topic reputation score is built on both the performance indicator $D_{\tau }$ and the data quality index $q_{\tau }$, and the result is scaled to the range of 0 to 1.

4.5. Execution of the Smart Broker System

4.5.1. The Continuous Execution

The last quality value $q_{\tau }^{w-1}$ of the data, streams is determined at any point in time $t_u$. This value can be different for each topic or group of topics. Parallelly, during each interval λ, TDQAM collects an amount of data up to the equivalent of $\lambda /\delta$, where $\delta$ is the intended publishing interval. Meanwhile, the TDM continuously monitors the arrival time of data with respect to $\delta$ within the interval $\lambda$ and the $D_{\tau }$ scores are available to the TRS after every sub-interval of $\delta$. The TRS (Algorithm 1 and Figure 4) calculates the reputation score of the topic after every sub-interval using the previous quality score $\left(q_{\tau }^{w-1}\right)$. When the largest of the windows in the groups of topics elapses, TRS receives the new quality score ($q_{\tau }^w)$ from TDQAM and calculates the reputation score by using current scores ${(D}_u$ and $q_{\tau }$).

Algorithm 1. Reputation Scoring at Time  ${\mathit{t}}_{\mathit{u}}$ for ith Topic  ${\mathit{\tau }}_{\mathit{i}}$ in  $\mathit{R}=\{{\mathit{\tau }}_1,{\mathit{\tau }}_2,{\mathit{\tau }}_3$}

$w_{12}\leftarrow last completed time window in W_{12}$, $v_{12}\leftarrow expected correlation for w_{12} in V_{12}$. $w_{23}\leftarrow last completed time window in W_{23}$, $v_{23}\leftarrow expected correlation for w_{23} in V_{23}$. $w_{13}\leftarrow last completed time window in W_{13}$, $v_{13}\leftarrow expected correlation for w_{13} in V_{13}$. Calculate $a\left({\tau }_1,{\tau }_2,w_{12}\right)$, $a\left({\tau }_1,{\tau }_3,w_{13}\right)$ and $a\left({\tau }_2,{\tau }_3,w_{23}\right)$. Calculate Q = {$q\left({\tau }_1\right), q\left({\tau }_2\right), q\left({\tau }_3\right)\}$ using Equation (12). Normalize Q, that is, for each $q\in Q, q\leftarrow q/\mathrm{m}\mathrm{a}\mathrm{x}\left(Q\right)$ $D_{ui}\leftarrow current drift score using Equation \left(5\right) for i^{th} topic at t_u since last drift score reset at t_0^{\lambda }$. $r_i=\frac{\alpha .D_{ui}+\beta .q_i }{\alpha +\beta }$ Reset $t_0^{\lambda }=t_u$ if $t_0^{\lambda }-t_u=\lambda$. Send $r_i$ to subscribers.

It is expected that the data will arrive at regular intervals of δ, but if there are delays, then the D_τ will gradually start dropping until it reaches µ, after which this drift score will hit 0. At the start of the window λ, the drift time reference ($t_0^{\lambda }$) is reset. If the data arrives back on track, this could help recover the score in a new window. Figure 4 illustrates the execution of the smart broker modules for a specific window and topic.

It is possible that due to the drift in time, the data for the quality calculation may be affected as not enough data may be available in the corresponding window w for peer data streams. In this case, the drift score will become 0, and the quality score cannot be calculated. If the group that contains the affected topic has more than three topics, then the affected topics are not accounted for in Equations (12) and (13). If it is just three topics, then it is not possible at all, and the smart broker will keep using the last successfully calculated quality score.

As with any conventional data broker, the smart broker too does not need to consider data that is older than the oldest running window across all topic pairs. Thus, while the smart broker needs to use a little more data, it can still be as fast as the conventional broker.

4.5.2. Computational Complexity of the Proposed Smart Broker

The smart broker, although working continuously in real time, deals with data that comes at regular intervals of δ, which is typically at least a few seconds. This means all the association scores are calculated periodically. The TDM and reputation scoring calculations are performed in O(1) and are computationally insignificant. For TQDAM, if the smart broker uses the 3-topic limit, the quality calculation for a single topic can be performed in O(|R|). Assuming that the total number of topics is $m\gg \left|R\right|$, calculating the quality of all topics is in O(m). In each topic pair, the window size is fixed, and there are no huge data points possible in the window. Thus, the calculation of quality can be performed without impacting performance.

4.6. Subscriber Request Assessment Module

If the requested data for a specific topic is available in the blockchain, SRAM will skip the recommendation step and return the requested topic’s data and its quality score.

But if the subscriber has requested data on the topic, which is currently unavailable or too poor in quality, then the SRAM performs a recommendation. A recommendation is different from a paired data stream. While paired or grouped data streams are expected to hold a steady relationship, they may not be a direct substitute, for example, sunlight and temperature are related but cannot be substituted for each other. The substitution aims to identify another topic that measures the same thing as the original stream.

The recommendation is performed by comparing the tags of the requested topic $\tau$ with the tags of each available topic $\tau \in \Gamma$ in the blockchain. A generic content-based filtering is used to measure the similarity between tags. It generates a similarity score between multiple documents. In this case, the “document” is composed of tags in the form of a short string. A minimum similarity score threshold is fixed system-wide to consider two strings as similar. Using this, the smart broker can create (${\Gamma }^{\prime })$ containing similarity scores of maximum $m$ topics, as shown in Equation (16), as follows:

$${\Gamma }^{\prime }=\left\{\left({{\tau }^{\prime }}_1, s_1^{\prime }\right),\left({{\tau }^{\prime }}_2, s_2^{\prime }\right),\hspace{1em}\dots ,\left({{\tau }^{\prime }}_{m-1}, s_{m-1}^{\prime }\right)\right\}$$

(16)

where $s_1^{\prime }\ge s_2^{\prime }\ge s_3^{\prime }\ge \dots \ge s_{m-1}^{\prime }$.

Then, SRAM retrieves all the corresponding reputation scores. With all the reputation scores, it will append these reputation scores for each recommended topic as follows:

$${\Gamma }^{″}=\left\{\left({{\tau }^{\prime }}_1, s_1^{\prime }·r_1^{\prime }\right), \dots ,\left({{\tau }^{\prime }}_{m-1}, s_{m-1}^{\prime }·r_{m-1}^{\prime }\right)\right\}$$

(17)

where $s_1^{\prime }·r_1^{\prime }\ge s_2^{\prime }·r_2^{\prime }\ge s_3^{\prime }·r_3^{\prime }\ge \dots \ge s_{m-1}^{\prime }·r_{m-1}^{\prime }$.

Before recommending ${\Gamma }^{″}$ to the subscriber, the SRAM checks the correlation matrix (see Equation (3)), obtains the relationship between the recommended and the requested topic, and incorporates it into the recommendation score, as shown in Equations (18) and (19) as follows:

$${\Gamma }^{‴}=\left\{\left({{\tau }^{\prime }}_1, s_1^{\prime }·r_1^{\prime }·a_1\right), \dots ,\left({{\tau }^{\prime }}_k, s_k^{\prime }·r_k^{\prime },·a_k\right)\right\}$$

(18)

where, $s_1^{\prime }·r_1^{\prime }·a_1\ge s_2^{\prime }·r_2^{\prime }·a_2\ge \dots \ge s_k^{\prime }·r_k^{\prime }·a_k$.

Finally, the SRAM will send the updated set ${\Gamma }^{‴}$ to the subscriber. This list of recommended topics can be large without filtering the location tags appropriately. Even after filtering the number of recommended substitute topics, it could still slow down the PS model. Hence, the SRAM can specifically restrict the number of recommended topics to k. An alternative strategy could be to set a lower limit on the recommendation score as follows:

$$f\left(s,r,a\right)=s·r·a$$

(19)

The exact formula for this may vary between smart brokers. If the subscriber accepts some recommendations from the set, ${\Gamma }^{‴},$ then SRAM responds with the new topic and its quality score.

5. Implementation and Evaluation

5.1. Setup Overview

This proposed smart broker is suitable for permissioned blockchain, where the identity of the publishers can be established, ensuring that the initial registration information is correct. We implement Smart Broker on the Hyperledger fabric with the modules implemented as chaincodes. We use a single node with Ubuntu 22 to deploy the Hyperledger Fabric blockchain platform, version v2.5.3, which runs on Go version go1.20.5 in Linux/amd64.

We have implemented a NodeJS client application. With this client application, publishers and subscribers can connect to the smart broker for data exchange. The client application is equipped with the identity provided by the smart broker. This identity authentication mechanism ensures secure interaction with the blockchain network, guaranteeing authorized access exchanged within the Hyperledger Fabric environment. The client application connects to the Hyperledger Fabric via the Fabric Gateway Client API.

5.2. Testing of Smart Broker Components

The implementation view of the smart broker is presented in Figure 5. The smart broker operates through two parallel running components: the Publisher End Module and the Subscriber End Module. The smart contracts within each module operate based on the following network conditions:

• Good communication: The blockchain network mainly operates at the application layer, so network delays do not hamper the application’s outcome. The IoT sensors would be sending data at an interval of at least 10 s, making any network-level latency variations and jitters insignificant to the drift score calculations.
  Figure 5. Implementation view of the smart broker.

  Figure 5. Implementation view of the smart broker.
• Distributed functionalities: The smart contracts all study fail-safe features. Due to their distributed nature, the functionalities will always be studied as long as there is at least one node. Multiple peer nodes are expected for a practical application, but for this paper, we tested the performance with one peer node.

The functionality of the smart contracts is as follows:

(1)

Publisher End Module:

The smart contracts within the publisher end module are working as follows:

• PTJ: This smart contract performs a topic registration process, which involves verifying essential tags and topic pairing. It updates the correlation matrix accordingly. The contract also stores topic details, including tag information, along with the updated correlation matrix. It also communicates with TDM, TDQAM, and TRS about the newly registered topic and its details so that TDM, TDQAM, and TRS can initiate their assessment of the topic.
• TDM: This smart contract retrieves publishing interval information for topics and continuously monitors the drifting score. It stores the drifting score after each interval, ensuring real-time tracking and analysis.
• TDQAM: This smart contract conducts quality assessments on topic data. It retrieves topic pairing data streams, correlation information, and publishing interval details from the ledger. Using this data, the topic’s quality is calculated, and the real-time quality score is stored in the ledger.
• TRS: The smart contract on the publisher side retrieves the topics’ assessment scores, quality scores, and drifting scores from the ledger. It then calculates the topic’s reputation score and stores it in the ledger.

(2)

Subscriber End Module:

• SRAM: This smart contract handles subscriber requests, providing data along with its quality score to the subscriber. It also prepares recommendation topics, if required, by calculating the similarity score, retrieving correlation information, and calculating the reputation score. Then, it prepares the recommendation score for the topics and sends it to the subscriber.

The components within the smart broker begin to assess the topic and its data based on configurations predefined and specified by the publisher (e.g., publishing interval) at the time of registration. The parameters for the experiment are shown in

Table 2. Parameter settings for testing.

Parameter Settings	Value
$\delta$	15 s
Delayed intervals	[δ, 2δ] in increments of 0.2
$\alpha$	(0, 1]
$\beta$	(0, 1]
Noise µ	1%, 2%, 5%, 10%, 12%, 16%, and 20% 2*δ

.

5.2.1. Preparation of a Correlation Matrix

We used real-world IoT datasets from Kaggle, for which the description can be found at [53]. This dataset is mainly prepared to predict air quality. It consists of five sensors recording different air parameters along with temperature and humidity sensors. It records the date and time of each sensor reading. The date and time of sensor readings start on 10 March 2010, at 6 p.m., and continue until 31 December 2010, spanning 10 months of recording. All records from the sensors are from the same type of machine (meaning from the same publisher). Moreover, the specified publishing interval is 1 h between readings.

However, for testing purposes only, the speed of feeding these data to the smart contracts is increased to a 15 s interval, which becomes the δ. The original dataset does not contain any noise or drift from the 15 s. We introduced the noise and delays for experimental purposes. The correlation matrix for testing TDQAM is prepared based on the data from this dataset and stored in the ledger.

5.2.2. Preparation of Correlated Topics for Testing

From the correlation matrix, we have prepared a set of correlated topics $({\tau }_1$ (sensor_1), ${\tau }_2$ (sensor_2), and ${\tau }_3$ (sensor_5)). This set will be used to test the TDQAM and assess the quality of Sensor 1’s data.

Table 3. Input parameters for quality testing.

Correlation Thresholds for Topic (sensor_1, sensor_2, and sensor_5)
${\mathit{v}}_{\mathbf{12}}$	0.81
${\mathit{v}}_{\mathbf{13}}$	0.86
${\mathit{v}}_{\mathbf{23}}$	0.86

lists the details of the topics.

5.3. Drift Score Testing and Results

To test TDM, we introduce delays in the intended publishing interval (δ) of ${\tau }_1$ to manipulate the timing of the data transmission. Our objective is to observe the time when TDM detects a 50%, 70%, or 90% drop in the transmitted data’s drifting score and determine the relationship between λ and δ.

We begin testing with 0 additional delay on δ, serving as a baseline for the initial data points (to establish normal system behavior). Then, we introduce delays, starting with a 1.2δ delayed interval and progressing in increments of 0.2% until reaching a 2δ delayed interval.

Drift scores are calculated at each publishing interval (δ). For the testing, we set the publishing interval (δ) to 15 s, meaning that normal data transmission occurs every 15 s.

When the data are sent with a delay of 3 s (delayed interval = 1.2δ), the smart broker takes around 60 s to detect a drifting score drop below 0.7, as shown in Figure 6. Doubling the data transmission delay to twice δ reduces the detection time to only around 30 s for detecting the same drop. Additionally, the smart broker can capture a 0.5 drop in drifting score in approximately 90 s when the delayed interval is 1.2δ. Conversely, it takes around 30 s to capture the same 0.5 drop when the delayed interval is doubled (2δ). Furthermore, a significant decrease in the detection time was observed for detecting a drop to a score of 0.3 with increasing delayed intervals.

The smart broker demonstrates quicker detection of score drops below 0.1, 0.3, and 0.5 as data transmission delays increase.

The results show that the higher the delays in the arrival of data, the quicker the drift score drops. A smart broker’s parameters have to be set properly to watch for a drop to a desired level and set the values for λ. For example, if the above data indicate that the typical delay in data arrival is 20% on 15s, then the λ should be set to 60 s (4δ) to watch out for a 0.7 quality score. To watch out for a 0.3 score, the λ should be 120 s (8δ). Note that this also acts as a net for greater delays as well.

5.4. Quality Testing with Different Levels of Noise

5.4.1. Quality Calculations with Noise and Fixed Windows Size

To test the quality performance, we test the continuous quality calculations given a fixed window. We set a window size of 300 s (i.e., 20 data points) for all $w_{ij} \in W_{ij}$, where $i,j \in R=\{{\tau }_1,{\tau }_2,{\tau }_3\}$. We consider the $v_{ij}$ as the normal expected correlation value for each $w_{ij}$ for corresponding pair of topics. This is shown in Figure 7a. We then introduce a topic ${\tau }_1^c$ which is the noisy version of the topic ${\tau }_1$ and simulate the running quality calculations as if the noisy topic ${\tau }_1^c$ was received along with the ${\tau }_2$ and ${\tau }_3$. This is shown in Figure 7b. The setting of proper $v_{ij}$ for each $w_{ij}$ is very important, and the ability to detect deviations is used for quality calculations. Both figures plot the actual quality calculations at all intervals of δ = 15 s, based on the last 300 s. But for a practical smart broker, the actual quality calculations will happen at the end of the window.

The results in Figure 7c indicate that between 300–1200 s and 1900–2300 s, the quality of the ${\tau }_1^c$ is significantly lower than the other two for the Normalized Group Specific Quality of ${\tau }_1^c$. Both ${\tau }_2$ and ${\tau }_3$ remaining close to 1. As the three-time series come closer to each other during 1200–1900 s, the quality for all of them goes closer to 1 before the ${\tau }_1^c$ dropping again. This shows that the smart broker is able to identify a rouge sensor in a group of three. However, if two sensors behave unexpectedly, the broker may not be able to identify a problem, in which case it will need a larger group.

However, in any case, the smart broker can at least accurately characterize unreliable sensors in a group and accurately measure the closeness of the sensor relationship within that group.

5.4.2. Understanding the Impact of Large Windows Size

For quality testing, we aim to establish the impact of the window size on the ability to detect quality drops. It is imperative that the proper window size be set so that higher levels of drops can be detected in quality before new data improve the quality. This is, however, dependent on the application goals of the IoT systems.

We calculated the quality of ${\tau }_1$ by corrupting its data by adding different levels of noise. We started corrupting the data with 1% noise and gradually increased it to 5%, 10%, 12%, 16%, and 20%. It is assumed that the window sizes are w₁₂ = w₁₃ = w₂₃ for this test. Figure 8 shows the quality assessment of TDQAM over time under different levels of noise. We increased the window size from 150s to 3000s and calculated the quality in the dataset for ${\tau }_1$. The actual smart broker will use a fixed window; this experiment shows the impact of the window size on the calculation of the quality. Each data series represents the quality calculations under different noise levels induced in the original data stream.

In Figure 8, it can be seen that for 1–5% noise, the quality score consistently remains higher than 0.8, while for 16% and 20%, the quality is consistently below 0.3. This is because the window size does not have any impact on whether the data is consistently poor or good. For middle-level noises, the quality keeps fluctuating with increasing window size.

As shown in Figure 9, when the data contains 10% noise, the smart broker requires approximately 220 s to identify a 30% decrease in quality. Detecting a 50% drop takes even longer, around the 1890s, under such low-noise conditions. However, with a 12% noise level, the smart broker can identify a 50% quality drop in just around 680 s. Moreover, it takes w = 151 s to detect a 30% drop and w = 360 s for a 40% drop, with the lowest w at 150 s. As the noise level increases, the time needed to detect these quality drops decreases. For instance, between noise levels of 16% and 20%, the smart broker can swiftly detect 70%, 60%, and 50% drops in quality, all within around w = 151 s.

The smart broker determines noise-induced drops in data quality, with detection times varying inversely with noise levels. As the noise level in the data increases, the smart broker becomes more efficient at detecting significant drops in quality, with detection times decreasing notably.

5.5. Reputation Scoring Patterns

We examine the patterns of the reputation scores of the topic by using the results of the quality assessment and the drifting scores obtained by introducing noise and delays in δ and analyze how they can impact the reputation score of the topic. The reputation score of the topic becomes closer to 1.0 under ideal conditions where there is no delay and the noise in the data is very low (around 1%). In the worst-case scenario, when there is very high noise in the data, such as 20%, and the maximum delay is double the δ, the reputation score drops to 0. Figure 10 shows the patterns of reputation scores under different noise and delay conditions.

5.6. Recommendation Testing

In the recommendation score testing, we used the same dataset that we have used for quality assessment, examining recommendation scores under various noise levels while keeping similarity scores and publishing intervals fixed. Suppose a subscriber requests data from sensor_4, which was not in the smart broker at the time. Since sensor_4 correlates closely with sensor_1 data (correlation coefficient of 0.64), it will appear on the recommendation list in the smart broker for sensor_4. Figure 11 shows the recommendation score of sensor_1 varying under different noise levels, with Sensor_1 having the highest recommendation score in Γ‴.

The rest of the data streams will follow the same pattern but at lower levels than sensor_1. We consider the three possibilities of a similarity score of 0.9, 0.95, and 0.99, and most of the tags associated are the same. We can see that with increasing noise from the potential substitute itself (in this case, sensor_1), the recommendation score of the recommended substitute decreases.

5.7. Performance Evaluation of Smart Broker

In this evaluation, we aimed to assess the smart broker’s performance within the Hyperledger fabric in terms of reading data, processing it, and writing the results into the ledger. We tested smart contracts (TDM, TDQAM, and TRS) within the smart broker deployed on a Hyperledger Fabric through a comprehensive simulation process. The simulation is to test the time consumption when the number of topics increases. At any given point in time, the smart contracts must calculate the quality of information on all topics. If the calculations are not simultaneous, then the time consumed would be naturally less, and the quality information would finalize much faster. If, however, the velocity of data is high and the smart contract needs to calculate the quality of all topics based on reading the data from the ledger, the time required to calculate the quality will increase. As such, we focus on this aspect of the performance. We varied the number of simultaneous topic reads, ranging from low (1 read) to high (5000 reads), keeping the channel number constant at 1, to assess the performance of the smart broker in taking the time to read, process, and write the results to the ledger. The network settings used in our evaluation are detailed in

Table 4. Network configurations.

Network Configurations	Values
Batch timeout	2 s
PreferredMaxBytes	500
Ledger Database	CouchDB
Block Size	10 transactions
Number of channels	1
Number of topics	1–5000

.

TDM (see Figure 12) shows a gradual increase in processing time as the number of simultaneous topic reads increases. Starting at 79.588 milliseconds for 10 reads, the time incrementally rises to 391.181 milliseconds for 5000 reads. It scales proportionally with the increase in topic reads.

With the TDQAM (Figure 13), the time varies more non-linearly, from about 90 ms for 10 simultaneous reads to 30 s for 3000 simultaneous topic reads.

With TRS (Figure 14), the time consumption is stable and linearly increases in processing time, starting at 89.586 milliseconds for 10 reads and rising to 133.958 milliseconds for 3000 reads. This gradual rise indicates that TRS efficiently manages increasing reads with minimal latency changes.

Assuming a typical IoT system can have several thousand devices (and corresponding topics), it is practical to implement the blockchain-based smart broker given that most IoT data will come in an update of more than a minute (δ > 60 s). Also, if multiple nodes of the Hyperledger are implemented, the time taken for calculating the quality components will also be reduced. Also, if using the Hyperledger fabric, multiple channels may be used to keep the data shared between peers (or publishers/subscribers) in the blockchain and potentially improve performance.

6. Characteristics of the Smart Broker

Smart broker inherits some of the key advantages of being implemented in the blockchain while having its own unique characteristics. This section also highlights some of the limitations and future studies needed to improve the smart broker.

6.1. Characteristics of the Blockchain Inherited by the Smart Broker

6.1.1. Advantage—Trust Management with Automation and Immutability

The execution of the smart broker mainly requires two parameters for each topic: $\delta$ and $w$, as shown in Figure 3. The modules in the smart broker continuously store their assessments based on $\delta$ and $w$ inside the ledger for each topic. The modules are implemented as smart contracts, which execute in a timely manner automatically. Being executed and implemented inside a blockchain makes the incoming IoT data immutable and trustworthy. Also, the calculation of quality and reputation uses the best source of data, which is shared among the smart broker peers.

6.1.2. Advantage—Registration of Publisher Topics

The smart broker’s recommendation feature relies on the publisher’s provided topic details. Hence, topics must be registered before being evaluated within the smart broker. When stored in the blockchain, such data can be verified before being processed for recommendation calculations. They are also immutable but can be updated if needed.

6.1.3. Disadvantage—Scalability Issues

While integrating blockchain with IoT, there could be a chance of scalability issues due to the continuous high flow of IoT data. In terms of the blockchain, adding more nodes is not difficult as the smart broker contracts can be extended to the new nodes. For example, in Hyperledger, the smart contacts remain on the channel, and new nodes are added to the channel, giving access to the ledger. In terms of adding new devices (i.e., topics), increased velocity does not increase the workload too much. The main issue could be about the topics, which are the size of the groups. Larger group sizes may need the smart contract to perform the comparison of a larger number of topics.

6.1.4. Disadvantage—Bad Network Condition

In this paper, we assumed a functional network with stable latency. Variable latency on the internet will not impact the smart broker where the δ > 60, as the typical latency change is up to 1–2 s in typical internet services. Rarely, the quality may be impacted, but it can be considered negligible in the context of the actual time gaps expected. Even if bad network conditions lead to a loss of information enroute to the blockchain and no data being recorded for a topic in time, reputations do not suffer for a long time. It will eventually recover if the subsequent data arrives on time.

6.2. Other Advantages of the Smart Broker

6.2.1. Topic Level Reputation Management

The smart broker continuously monitors the reputation of topics by assessing their data quality and reliability in providing data within specified intervals. The modules involved study independently and rely on the latest available values of the components of the reputation scores. This ongoing assessment enables the smart broker to update the reputation of topics in real time. Consequently, when a subscriber requests data for a particular topic, the smart broker can promptly provide its reputation score. This real-time updating and sharing of reputation scores build trust between subscribers and the IoT data, ensuring transparency and reliability in the data exchange process.

6.2.2. Recommendation for Subscribers

The smart broker is able to monitor the relationship between the data streams continuously. Thus, it becomes easy for it to figure out substitutes for any given topic. This recommendation is based on both the reputation of the other topics as well as the similarity of those topics and the missing topics. Both the reputation and the recommendations can be calibrated according to the nature of the IoT systems, and certain aspects of the reputation and recommendation scoring may be magnified over others.

6.2.3. Real-Time Monitoring

All the modules within the smart broker perform real-time assessments of the topic data to continuously monitor its quality and reliability in terms of providing data within the required time interval.

6.3. Future Works and Limitations

The proposed smart broker has four key Equations (10), (12), (15) and (19) to determine the different scores within the whole system. These equations may be further improved according to blockchain performance efficiency and the nature of the relationships among the data streams. The following areas can be further enhanced:

6.3.1. Similarity Detection in a Smart Broker

The method for finding data streams with similar time series can be improved. In this paper, we assume manual data stream grouping, which requires a degree of human intervention and can introduce the possibility of tampering, making it unreliable. Also, if the nature of a relationship changes, then it has to be re-entered into the system periodically. Future improvements can be made where the blockchain keeps track of the actual relationship in real time and updates the value of the relationship matrix. It may find new relationships automatically and upgrade/downgrade existing relationships as well.

6.3.2. Non-Linear Relationships

The proposed approach needs to have a fixed $w,\lambda ,$ and δ. While having a fixed δ is not a big difficulty, having the right window size ($w$) is critical to the success of the TDQAM. In this paper, we use simple linear covariance to demonstrate the effectiveness of the proposed smart broker. However, in the future, smart brokers will need to use non-linear relationship measurements as well. This may be performed with neural network methods.

Furthermore, we only considered the most commonly used periodic sensor-oriented IoT application configuration here. Future studies can modify Equations (10), (12) and (19) as needed for different IoT application requirements.

6.3.3. Self-Checks

In this paper, we did not consider matching a stream with its historical values. This is primarily because just checking with its own historical values cannot account for actual environmental variations that are not a quality problem. However, based on the application, this factor can also be included in TDQAM alongside the streams’ peer assessment.

6.3.4. Speed of Detecting Variations

Currently, the proposed framework adjusts itself to provide the reputation score of the topics based on the specified windows of time. This could be improved if the smart broker could adjust the window itself based on external factors or information to make it more efficient.

6.3.5. Ability to Detect Problems

The proposed method can detect unexpected variations and report continuously in a reasonable time with respect to the periodicity of the data streams. If the variations disappear, then the reputation is restored. However, the depth of the actual problem is not identified by the current system. Unfortunately, even with a better version of quality assessment, it may still be difficult to identify if the variations are actually a problem. However, this aspect may be outside the scope of a smart broker and part of the subscriber applications.

6.3.6. Performance Inside the Blockchain

In this paper, we discussed the application of the smart broker inside a blockchain, thus inheriting the advantages of automation, accountability, and privacy that come with blockchain. We showed that the smart broker can be implemented in the blockchain. However, further testing and design issues need to be addressed, particularly regarding data storage. The subscriber only needs a specific window of the data and does not need older data, but blockchains typically keep storing information forever. The exact storage, exchange, and purging of data need to be investigated further.

6.3.7. Handling Event-Based Publishing Intervals

In the context of IoT, it is possible that the publishing interval may be event-based and happen at random times. In those cases, the quality would depend on other factors, such as the number of events in a given window.

6.4. Real-World Applications

The smart broker-based PS architecture can be used in any context where current PS applications work. The proposed method simply provides an opinion about every topic based on the recent performance of the individual publishing entities, that is, the IoT devices. Let us consider a smart city application, where the smart broker can be used to monitor various data streams from different sources to ensure the accuracy and reliability of the data used for critical decision-making processes. The possible publishers are as follows:

• Traffic Monitoring Sensors, including traffic cameras, speed sensors, and vehicle counters. These publishers can provide topics such as traffic flow, vehicle speed, and vehicle count.
• Environmental Sensors, including air quality monitors and weather stations, can provide information on topics such as the air quality index, temperature, humidity, and pollution levels.
• Public Transit Systems, including buses, trains, and trams, can cover topics such as transit schedules, vehicle locations, and passenger counts.
• Emergency Services, including police, fire departments, and ambulance services, can provide topics such as incident reports, response times, and emergency vehicle locations.
• Infrastructure Sensors, including roadway sensors and bridge monitors, can offer topics like road conditions, structural integrity, and maintenance schedules.

All these entities will have a semi-permanent relationship with each other. These relationships can be captured in the relationship matrix, either manually or automatically, by analyzing historical information. Once the normal relationship is identified, any abnormality can be identified in real time. Based on the reputation scores, the smart broker recommends the most reliable information to city officials, optimizing city operations and enhancing citizen safety and well-being.

7. Conclusions

This paper has proposed a blockchain-driven smart broker designed for publisher-subscriber systems. It focuses on real-time tracking and monitoring of the reputation score of the topic’s data based on their quality and transmission intervals. We have proposed a mechanism capable of measuring drifts in the data and imposing penalties as well. Additionally, we implement a recommendation approach within the smart broker aimed at building trust between the subscriber and the recommended data. This approach provides recommendation scores derived from topic reputation within the smart broker, considering both data quality and transmission intervals. The proposed smart broker was tested using real-time datasets, demonstrating its capability to effectively handle and process IoT data in real-time scenarios while running from inside a blockchain. Every component of the smart broker can be improved and tailored for specific IoT applications.