**5. Experimental setup**

An evaluation based on several experiments is presented to validate the proposed system. The proposed authentication system is implemented through some simulators such as Cisco Packet Tracer [9], iFogSim [10], and Ethereum smart contracts utilizing Solidity [11]. This smart contract is tested, and the simulation is run through Remix Ethereum. This IDE offers various features such as the creation, deployment, testing, and debugging of smart contracts. The network layout of the system and simulations are executed in Ethereum Remix IDE and Cisco Packet Tracer.

Data from the metrics are collected such as the time needed to send packets from user devices to the fog nodes using Cisco Packet Tracer, the energy consumed, the cost of execution in the cloud, the total time required for module migration using iFogSim, and the transaction cost, execution cost, and miner fees are recorded for both registration and authentication requests through the blockchain network.

Simulations are run through Cisco Packet Tracer to replicate the fog network with nodes and determine the time needed to send packets from user devices to the fog nodes.

#### **5.1 Cisco packet tracer simulation**

The network is replicated in Cisco Packet Tracer [9]. Fog servers (nodes) and user devices are used to run simulations and tests on a variety of packets and protocols (HTTPS, SSH, SMTP, ICMP), and multiple requests are made on both wired and wireless networks to find out how long it takes to send authentication packets on the network. For the purpose of this experiment, these packets were chosen because they are frequently used for secure communications over computer networks [4].

**Figure 8** represents the developed configuration of the proposed network scheme in Cisco Packet Tracer. The development was taken as a reference to the configuration given by [12], also the conceptions developed in [13]. **Table 1** shows the relation of components of the proposed network.

The results for simulation showed that all the packets are delivered in 40.049 s in a wired and wireless network, considering delivering SMTP packets, SSH packets, and HTTPS and ICMP. The time required to authenticate various packets using the proposed method is shown in the obtained results. This demonstration can quickly and effectively handle authentication requests, scale to multiple devices in a fog

**Figure 8.** *Configuration of proposed network scheme in packet tracer.*

*A Simulation Model of a Blockchain-Based Decentralized Patient Information Exchange… DOI: http://dx.doi.org/10.5772/intechopen.109591*


#### **Table 1.**

*Devices used for the simulation.*

computing environment, and is suitable for use on edge devices. The used version of Cisco Packet Tracer was 8.1.1.

#### **5.2 Simulation results in iFogsim**

iFogSim simulation toolkit is developed upon the fundamental framework of CloudSim. CloudSim is one of the wildly adopted simulators to model Cloud computing environments. A customized Fog computing environment with a large number of Fog nodes and Internet of Things (IoT) devices (such as sensors and actuators) can be simulated with the help of iFogSim. However, the classes in iFogSim are annotated in such a way that users without prior knowledge of CloudSim can quickly and easily define the policies for Fog computing's infrastructure, service placement, and resource allocation. When simulating any application scenario in the Fog computing environment, iFogSim employs the Sense-Process-Actuate and distributed dataflow models. It makes it easier to evaluate end-to-end latency, network congestion, power consumption, operational costs, and customer satisfaction with QoS [14].

iFogSim2 is a simulator [15], which is an extension of the iFogsim simulator and addresses distributed cluster formation among Edge/Fog nodes of various hierarchical levels, microservice orchestration, and service migration for various mobility models of IoT devices.

The new iFogSim2 simulator components are loosely coupled to support various simulation scenarios. As a result, the components (Mobility, Clustering, and Microservices) can be used solely for simulation or integrated for more complex scenarios [15].

In the Healthcare solution of Parkinson's Disease, body-connected IoT devices perceive the health context of the users through a Client application module. Generally, the IoT devices are usually connected to smartphones, but in this particular case, the sensors are inside the same smartphone.

For the corresponding application, the smartphones serve as the Application gateway node. These nodes prepare the sensed data from IoT devices. The application's data analysis and event management operations are carried out in upper-level Fog computational nodes unless the Application gateway node's resource availability

meets the requirements. Application gateway nodes select appropriate computational nodes in the second scenario to deploy additional application modules and initiate actuators based on the results of those modules [14].

In the IoT-enabled Parkinson's Disease Patient monitoring healthcare solution using iFogSim was simulated the necessary Fog environment. The application model for the IoT-enabled healthcare solutions is represented in **Figure 9**.

**Figure 9.**

*Application model for IoT-enabled healthcare case study [14].*

The system and the application along with the required guidelines to model them in iFogSim are an n-tire hierarchical Fog environment. As the rank of Fog levels goes higher, the number of Fog devices residing at that level gets lower. Fog devices form Clusters among themselves and can be mobile. IoT devices (smartphones) are connected to lower-level Fog devices [14]. The sensing frequencies of IoT devices are different. The application model consists of four modules with a sequential unidirectional data flow. The requirements of the application modules are different, and each application module can request additional resources from the host Fog devices to process data within the QoS-defined deadline. The results of the simulation are shown in **Figure 10**.

#### **5.3 Simulation smart contract through remix Ethereum**

Ethereum is a decentralized, open-source blockchain with smart contract functionality. The Ethereum network is a well-established blockchain network that allows people to actively develop new and innovative applications and products that directly tie to Ethereum and use its native cryptocurrency, ether. This allows people to use a blockchain network that already has nodes and avoid the need to set up self-hosted nodes for testing. However, some limitations include long transaction times and high gas prices [16]. For the simulation of blockchain in IoT communications, Ethereum was the single simulator. This meant that Ethereum was used in hashing and encoding. In smart devices, Ethereum was used as the base network for storing data via smart contracts and generating hashes [16]. For all these properties, Ethereum was selected for the simulation.

*A Simulation Model of a Blockchain-Based Decentralized Patient Information Exchange… DOI: http://dx.doi.org/10.5772/intechopen.109591*


*Results of simulation IoT-enabled Parkinson's Disease Patients monitoring healthcare solution using iFogSim.*

**Figure 11** depicts the Ethereum-enabled fog nodes of the proposed system architecture. Five main participants with Internet access to Ethereum smart contracts make up the architecture: fog nodes, users, administrators, and cloud servers that store IoT data. Although IoT devices have a unique Ethereum address and public and private

**Figure 11.** *System architecture with fog nodes that can use Ethereum [17].*

keys, they do not interface with the smart contract or have connectivity. In the case of fog and cloud nodes, each participant has a unique Ethereum Address (EA) and interacts directly with the smart contract via an Ethereum client or a front-end application or wallet for administrators and end users [17].

Ethereum Remix IDE is chosen for this experiment for its features, which allows for the development, administering, and deployment of smart contracts in a virtual blockchain environment.

The simulation model is displayed in **Figure 12**. In step 1, User A presents data and sends a registration request to the blockchain-enabled fog node via the edge device. User A is registered as a new user in step 3, while user data are stored on a distributed ledger by the blockchain-enabled fog node in step 2. User B presents data and sends an authentication request to the blockchain-enabled fog node through the edge device in step (4). At the following stage (5), the blockchain-empowered fog node affirms that Client B's information is legitimate and exists in a distributed ledger. The user is then verified or denied. The exchange cost, execution cost, and miner fees are recorded for both registration and authentication demands through the blockchain network [4].

**Figure 13** shows the sequence diagram of exchange messages showing a successful authentication of the end user to the IoT Device.

In order to carry out the authentication scheme, the system entities interact in two primary ways; namely: interactions between the on- and off-chains, as shown in **Figure 13**. A sequence diagram for a secure session connection between an end user and an IoT device following successful authentication is depicted in **Figure 13**. The admin first creates the smart contract, registers the IoT devices, and maps them to a fog node using the *addDeviceFogMapping* function in the on-chain activity. The Ethereum Address (EA) is unique to each fog node and IoT device. Using the *addUserDeviceMapping* function, the administrator can also grant access permissions to specific IoT devices to end users. On Github, the entire smart contract logic, lists, rules, and code for the authentication registry are also made available to the public [18].

*A Simulation Model of a Blockchain-Based Decentralized Patient Information Exchange… DOI: http://dx.doi.org/10.5772/intechopen.109591*

#### **Figure 13.**

*Sequence diagram of exchange messages showing a successful authentication of the end user to IoT Device [17].*

The end user first sends an authentication request to the smart contract using the request Authentication function, specifying the EA of the IoT device, before attempting to access that device. The user's saved list of authorized IoT devices will be reviewed by the smart contract. A rejected request event will be generated in the event that the user is not authorized to access that device. Otherwise, the smart contract will issue an acceptance event and an access token if the user has permission to do so,*TokenCreated =* (*UID*,*T*, *Δ*, *EAUser*, *EADevice*, *EAFog*). By definition, the event is broadcasted to all users and fog nodes [17].

The rest of the exchange messages showing a successful authentication of the enduser to the IoT Device are detailed and described in [17]. A view of the implementation of the given solidity software code given in the available Github is shown in **Figure 14**.


#### **Figure 14.** *Implementation of the simulation smart contract through the IDE Remix Ethereum.*
