Message Scheduling in Blockchain Based IoT Environment With Additional Fog Broker Layer

Recently researchers and companies have shown significant interest in merging blockchain and the Internet of Things (IoT) to create a safe, reliable, and resilient communication platform. However, determining the proper role of blockchain in existing IoT contexts with minimum implications is a challenge. This work suggests a message schedule for a blockchain-based architecture with two access-level setting filters for incoming messages: critical and non-critical. The proposed work of the researchers divides the fog layer into two parts: action clusters and blockchain fog clusters. Similar to the three-layered IoT architecture, the action cluster and the main cloud data center work together for critical message requests. The blockchain fog cluster is dedicated to only the blockchain application’s requirements. In the fog layer, a fog broker is used to schedule critical and non-critical messages in the action and blockchain fog clusters, respectively. The proposed technique is compared to the existing Dual Fog-IoT architecture. The solution is also tested for fog and cloud computing resource utilization. The findings demonstrate that this architecture is feasible for varying percentages of receiving critical and non-critical messages. In addition to the inherent benefits of blockchain, the suggested paradigm reduces the system loss rate and offloads the cloud data center with minimal changes to the existing IoT ecosystem.


I. INTRODUCTION
The Internet of Things (IoT) is a remarkable revolution-17 ary technology that connects and empowers things to make 18 independent decisions in a smart environment. The modern 19 technology of electronic gadgets and communication tech-20 nologies has aided in achieving an unexpectedly quick devel-21 opment in its expansion [1]. As a byproduct of IoT, there are 22 billions of gadgets connected to the Internet [1], [2]. It is 23 a reality that with the development of novel hardware and 24 software technologies, the growth of IoT is running beyond 25 predictions made by the business and researchers previously. 26 The engagement of a third party to maintain data in a Cen- 27 tralized Datacenter (CDC) [1], [3] has raised numerous key 28 The associate editor coordinating the review of this manuscript and approving it for publication was Chunsheng Zhu . concerns, and these issues may be acting as a barrier to 29 achieving its long-term goals. 30 In 2006, Cisco unveiled Fog computing [1], [4], which 31 brings processing capabilities to the edge of the network to 32 solve the difficulties of scalability, latency, cost, and energy 33 consumption that come with IoT design. The fog layer exists 34 at the network's access level to alleviate storage load from a 35 data center and respond to requests with low late. The indus-36 try is currently leveraging the three-layer IoT architecture [5]: 37 The device layer contains sensors, actuators, and smart 38 devices; layer two is the fog layer, which provides a quick 39 reaction to critical applications and is made up of devices 40 such as smart gateways, routers, and dedicated fog computing 41 devices; and layer three is data center, which is made up 42 of fog devices connected to cloud gateways. Implementa- 43 tion of a fog layer into cloud infrastructure is expected to 44 decrease latency [2], [6] however, a lack of trust may persist as 45 Message scheduling is a process in which action is carried 99 out by a distributed system's broker (scheduler) mechanism 100 [9], [13], it makes use of message contexts or any other type 101 of information that may be considered according to their 102 priorities. Messages are categorized in the proposed system 103 based on their features and quality of service (QoS) spec-104 ifications, and applications are divided into two categories: 105 critical and non-critical. An IoT ecosystem can provide dif-106 ferent types of services. The Service-Oriented Architecture 107 (SOA) [14] specifies how these services are represented and 108 communicated [10], [15]. SOA is an architectural strategy 109 that improves the service delivery effectiveness of current tra-110 ditional systems while keeping their most significant charac-111 teristics. This technique has attracted the interest of business 112 groups due to its adaptability, particularly in the creation of 113 world-leading services and applications of cloud computing 114 and IoT. New protocols, communication technology, and gad-115 gets are being explored and deployed to provide a sustainable 116 connection among various SOA services. This allows these 117 massive physical world objects to communicate and interact 118 with their surroundings leading to growing computational 119 capacity. 120 Generally, IoT data sets are sent to cloud services for 121 processing. Time-sensitive IoT applications [11], [16], on the 122 other hand, cannot withstand the considerable latency that 123 data may face when transferred to the cloud. Fog computing-124 based alternatives for these types of applications are becom-125 ing increasingly appealing because of the reduced latency. 126 Growing prevalence of fog base stations, the researchers 127 present in this work a framework for QoS-aware fog service 128 provisioning, which enables IoT application activities to be 129 scheduled on a fog broker. To facilitate IoT applications in 130 meeting their QoS requirements, a fog broker component can 131 apply various scheduling strategies [15], [17], [18], [19], [20]. 132 The simulation results demonstrate that by employing a few 133 basic tactics, it is feasible to maintain low application latency 134 and spread the processing load throughout the fog nodes of 135 the cluster. 136 The current studies have tended to link blockchain with 137 IoT, and these can be categorized into two types. That one 138 is a complete transfer of IoT to the blockchain, in which 139 all sensor-embedded devices are connected directly with one 140 another without the need for an intermediary. Products like 141 EthEmbeded [16], Ethraspban [17], Raspnode [18], and Bit-142 main [19] are illustrations of the existing devices. However, 143 a complete transition of IoT to a blockchain is not sustainable 144 since blockchain mining is a complex task that necessitates 145 high computational power, which is currently provided by 146 the application of specific integrated circuit chips [20] and it 147 is difficult to implement blockchain on resource-constrained 148 gadgets in an IoT ecosystem [21]. The second class focuses 149 on improving one of the three levels of the existing IoT 150 ecosystem with a new layer devoted to running blockchain 151 protocols.
handles it at the fog broker because access points have limited 192 resources such as processing power, memory, and storage.

193
In the researchers' solution, the fog broker performs mes-  The network edge is a resource-constrained area, whereas 211 blockchain implementation necessitates a large amount of 212 computational power. Authors in [22] and [23] have pre-213 sented the notion of accessing blockchain services from the 214 cloud. The suggested proposal is a viable solution for public 215 blockchains, but it gives full accessing power in the hands 216 of a third party, which is undesirable in the case of a private 217 blockchain. The blockchain must be store on an IoT net-218 work or in fog in private blockchain systems. The suggested 219 IoT-based architecture in [23] and [24] focuses on message 220 scheduling in IoT clusters. Each group has a designated 221 broker that collects data from the nodes of its members and 222 transmits it to the sink. A scheduler is built at the broker 223 level to determine which message will be transmitted first. 224 Compared to traditional LEACH, the major considerations 225 for selecting a broker are residual energy and distance. The 226 suggested design has a longer network lifetime, lower overall 227 energy dissipation, and faster reaction time.

228
The authors of this study developed a GMM (Group 229 Message Management) system to efficiently coordinate the 230 delivery of alerts from IoT devices to client end devices 231 [24], [25]. The scheduling module divides the customers into 232 groups based on their requirements and assigns each group 233 an ideal period. The caching module reduces the number of 234 alerts required to group client requests by setting the max-235 imum age value. To reduce bandwidth and energy, the sug-236 gested module aggregates alerts from multiple IoT devices 237 requested by the same group request. The integration of edge 238 and cloud infrastructure with IoT to facilitate its execution 239 and demanding computing applications has received atten-240 tion recently. In terms of security, platform independence, 241 multiple application execution, resource management, and 242 many real-world frameworks strive to provide such integra-243 tion. The fog integration framework was suggested in this 244 study. It helps the developers to create IoT  proposed the destination prediction algorithm on the Inter-254 net of Vehicles (IoV) to predict the location of any vehicle 255 using machine learning. First of all, a real-time prediction 256 framework is proposed to explore the location of a vehicle 257 while traveling. The benefit of the prediction scheduling 258 algorithm is that it chooses the most suitable service provider 259 for resources. In this proposed solution, fog services are used 260 to process and store location-based information. When data 261 is acquired from a network cluster, the use of the Internet 262 of Things raises various security concerns. IoT security, data 263 collection integrity, and data management may be improved 264 by Blockchain technology. In [27] and [28] authors have 265 proposed a context-aware technique for on-chain data allo-266 cation in a blockchain-based IoT system. Furthermore, this 267 system is based on fuzzy logic that was developed for data 268 VOLUME 10, 2022     created by smart devices, has resulted in data outsourcing. 325 However, in order to handle such a massive data storage 326 site, centralized data centers, such as cloud storage, cannot 327 afford to transmit data from an untrustworthy source. The 328 article [33], [34] offers a novel blockchain-based distributed 329 cloud method with software-defined networking (SDN) to 330 overcome some vital problems, allowing control fog nodes 331 at the network's edge to meet the appropriate design criteria. 332 The suggested concept includes a distributed cloud infrastruc-333 ture based on blockchain technology that provides low-cost, 334 secure, and on-demand access to the cheapest architecture in 335 an IoT-based network.

336
Light Chain [34], [35] a resource-efficient lightweight 337 blockchain structure described by the authors of this study, 338 is ideal for power-constrained IoT devices. They provide 339 green computing to encourage IoT device support, as well 340 as Light Block, a lightweight data technique that simplifies 341 broadcast data contents and also creates a unique unrelated 342 block offloading filter to keep the blockchain ledger from 343 expanding endlessly while maintaining blockchain traceabil-344 ity. To complete a job, each procedure requires computing. 345 Scheduling is the process of assigning a job to a resource for 346 computation. A privacy-aware, upgraded blockchain-assisted 347 task scheduling protocol is presented to determine the appro-348 priate virtual resource assignment for work. In terms of 349 efficient resource assignment, privacy, message exchange, 350 and the outcomes of this system are better. To get the most 351 out of cloud computing, the article [35] approach employs 352 blockchain as a service. The suggested technique [36] has 353 shown to be a feasible solution to improve wireless sen-354 sor network trust and dependability. Reference [36] the 355 study proposes a unique technique for seamless network 356 communication that extends the LEACH protocol with 357 improved network availability, fault tolerance, and energy-358 efficient message scheduling. By eliminating recurrent sens-359 ing, consolidation, and message scheduling operations, 360 this strategy not only handles the problem and promotes 361 availability, but also saves energy for non-broker and 362 broker nodes.

363
With the support of a decentralized mechanism to govern 364 edge nodes' task execution with heavy resources to reduce 365 task delay, the suggested LAAECHA [37] strategy was devel-366 oped. The edge network's availability and dependability are 367 ensured by the high availability system, in comparison to 368 traditional cluster-based techniques for group construction 369 with dispersed mode execution.

370
In [38] the researcher suggested a QoS message scheduling 371 method that is more oriented on service provisioning with 372 the objective of differentiation strategy. Messages are divided 373 into two categories: high priority (HP) and best effort (BE), 374 with the latter transmitting all other non-critical data. The 375 goal is to allow IoT networks to distinguish between mission-376 critical and non-mission-critical communications, achieving 377 the best possible balance using a cross-layer design pro-378 cess that includes network-layer routing and application-layer 379 QoS-aware message scheduling.  The researchers [46] investigates a trustworthy distributed 419 audit approach for cloud job scheduling, as well as the for-420 mulation and construction of a blockchain-based cloud work  [47], and the researchers show that the nascent 437 ASI has the ability to address the problem. Unlike traditional 438 AI, ASI is combined with computer and communication tech-439 niques, allowing it to deal with the explosion of social ties 440 from the standpoint of social computing. IoT devices will be 441 able to use social context to improve. These devices offer and 442 adapt the material. These devices also give thanks to social-443 centered fusion computing and communication.

444
The movement of computational from the cloud to the edge 445 of the network is discussed in [42] and [48]. Fog computing 446 works closer to the end-user, on the network edge, providing 447 precise service delivery with a fast reaction time, eliminat-448 ing delays and network faults that might disrupt or delay 449 the decision-making process and the delivery of healthcare 450 services. The benefits of combining IoT with fog computing 451 are demonstrated through an architectural model and a series 452 of use cases. The authors [43], [49] to lessen the strain on 453 consumers and electricity-producing systems, a three-layered 454 approach cloud is enabled and fog architecture is proposed. 455 The fog server layer is connected to the end-user layer by 456 clusters of buildings. The fog layer serves as a bridge between 457 the end-user layer and the cloud layer. Three load balanc-458 ing techniques are employed for resource allocation: Round 459 Robin (RR), throttled, and the suggested Particle Swarm 460 Optimization with Simulated Annealing (PSOSA).

461
The major goal is to improve the performance of the cloud 462 environment by lowering overall costs by routing incoming 463 requests to key nodes. Using a cloud analysis simulator, the 464 article [44] provides an empirical evaluation of both load 465 balance and service broker strategies. The goal of the analysis 466 is to look at three alternative load balancing algorithms and 467 see how they behave (Round Robin, Throttled, and Active 468 Monitoring). Table 1 presents a comparison of the proposed solution 470 with already proposed literature with respect to the imple-471 mentation, processing, and storage of the blockchain in the 472 IoT environment. It also compares the different solutions 473 either to perform the differentiation of messages into emer-474 gency(critical) and delay-tolerant messages or not. In the 475 proposed solution, the processing is performed on cloud to 476 save the processing resources and storage is done on fog to 477 avoid the delay.

479
As illustrated in Figure 1, blockchain is implemented in the 480 segregation of processing, i.e., mining and storage, at distinct 481 tiers of the proposed IoT three-layered architecture [48], [50]. 482 To prevent placing control of the blockchain in the hands of 483 a third party, blockchain storage is done at the fog layer. Not 484 only does the proposed architecture use blockchain for segre-485 gation, but it also handles critical and non-critical messages 486 separately. Fog is divided into two parts: The Fog Action 487 Cluster (FAC), which response quickly to critical messages, 488 and the Fog Blockchain Cluster, which handles blockchain 489 communications. This section contains in-depth descriptions 490 of each layer.

492
The proposed solution structure is based on the three-layered 493 architecture of IoT as shown in Figure 2. The three-layer 494 architecture comprises IoT devices, fog, and cloud lay-495 ers [49], [51]. The device layer's functionalities are described IoT deals with a variety of devices and applications, includ-503 ing the critical and non-critical [50], [52]. The network 504 must respond to a wide range of queries. Critical applica-505 tion requests must be responded quickly, and blockchain 506 has the potential to store significant delay-tolerant requests. 507 For instance, critical communications include fire alarm sys-508 tems, traffic accident systems, medical crises, etc. If a fire 509 is detected in the building, the fire alarm system discon-510 nects the whole building's electricity and dials an emergency 511   Non-critical messages are the most suitable candidates for 519 storage in blockchain blocks [51], [53]. In IoT devices, 520 processing, storage, transmission, and battery power are all 521 constrained [52], [54]. Because of the aforementioned lim-522 its, implementing blockchain at the device level is very 523 difficult [55]. Blockchain processing is handled by a cloud 524 service, while storage is handled by the fog layer in this 525 system. Some devices, like Bitmain, Raspnode, and Ethrasp-526 bian, can run lightweight blockchain client software. In some 527 cases, replacing current IoT devices with blockchain-capable 528 devices is problematic. IoT layer is unaffected by the 529 researchers' suggested method. The access point is a forwarding device located at the edge 532 of the network. To forward messages to the fog layer for 533 additional processing, all devices obtain the message for-534 warding services of an access point. As indicated in Figure 3, 535 when a device enters the network, its registry is conducted 536   Receive the message from the selected Active node 2: Msg i (Msg_header,Msg_Payload,Priority i )

7:
Put the message into Q2  Non-critical messages provide more flexibility with 565 respect to time constraints. The smart grid, smart farm-566 ing, selling and buying, online shopping, and supply chain 567 all require high processing power, reliability, confidential-568 ity, authorization, and tamper-proofing. In the traditional 569 blockchain process, each device has its own local memory to 570 hold transactions for block formation, but in the present case, 571 the block is formed on a FB. This architecture implements 572 a publish-subscribe model [56], [58] to forward messages 573 from the IoT layer to the appropriate cluster of the fog layer. 574 A publisher, a broker, and a subscriber are the three com-575 ponents of this model shown in Figure 4. The publisher is a 576 collection of data-generating devices like sensors, computing 577 devices, or any other object having embedded sensors. A broker is a message filtering device that multiplexes the messages 579 [57], [59] according to the subject subscribed to by some sub-580 scribers. A subscriber is a device that receives data generated 581 by the publisher. In the present model, subscribers are AC 582 and BFC that subscribe to critical and non-critical messages 583 respectively.

584
The proposed algorithm has queue processing and is the 585 main processing operations regarding the time complexity.   Figure 5. For blockchain pro-614 cessing, the FMC msg queue subscribes messages from non-615 critical msg queues. It is transmitted to all FBNs when the 616 queue size surpasses the block size. The FBN's FBCH sends 617 blocks to the cloud for mining purposes. The cloud provides 618 mining services for the blockchain. After mining, a block is 619 returned to the FBN. On the other hand, a critical message 620 generated at the device layer reaches the AC. The message is 621 transmitted to the cloud for storage after the relevant process 622 is completed swiftly.

623
Miners use a variety of mining technologies for this goal, 624 including CPU mining, GPU mining, FPGA mining, mining 625 pools, ASIC mining, and others. The problems can only be 626 solved by trial and error. As a result, in order to find answers 627 rapidly, miners need more processing capacity. Cloud mining 628 entails renting or buying mining equipment from a third-party 629 cloud provider, who is also responsible for maintaining the 630 equipment. Network bandwidth is used to send a block for 631 mining in the cloud after the mining block is received back 632 from the cloud. In this way, blockchain will be stored on fog, 633 which will be accessible via local accesses. In this manner, 634 it can use network bandwidth more effectively. Due to local 635 access from the fog layer, the delay will be minimized.

636
The Proof of Work (POW) method, often referred to as 637 mining, is one of the most well-known processes for achiev-638 ing consensus, and miners are nodes that carry out mining. 639 Miners work on difficult mathematical puzzles that need mas-640 sive processing power. In the present solution, non-critical 641 messages are packed in the form of blocks by the FB, and 642 then the blocks are broadcast to the blockchain fog cluster. 643 One predefined cluster head forward block is sent to the cloud 644 for mining in the cluster. After mining from the cloud, a nonce 645 is received by all cluster nodes. Each node verifies the block 646 hash and if it is correct, it will be included in its blockchain. 647 VOLUME 10, 2022

648
The proposed architecture implements two configurations.

649
In this section, the workings of each configuration are 650 elaborated. Figures 6 and 7 illustrate the corresponding 651 configurations. Configuration 1 is for critical and configura-652 tion 2 is for non-critical messages.

653
By utilizing distributed network design, blockchain not 654 only delivers security, stability, and a trustworthy network 655   The typical Markovian assumptions of inter-arrival and ser-698 vice times are used in this model. The average rate of arrival 699 is λ and the average rate of service is µ. The system's capacity 700 is assumed to be finite, say N. There is just one FB. The 701 queue follows the first-come, first-served principle. When a 702 message enters the queue, it will have to wait for a specific 703 amount of time for the service to begin. With parameters ζ , 704 the waiting times follow an exponential distribution. Poisson process with a rate (λ > 0) and a mean inter-709 arrival time of 1/λ. 710 2) Message service times are exponential random vari-711 ables with rate µ > 0 and mean service time 1/µ, 712 0 < λ < µ. that are independent and identically 713 distributed.  P n (t) probability of n messages in the system, 1 message in 717 the service, and n-1 in queues [60], [61] 718 dp 0 (t) In case of a steady state lim t−∞ p n (t) = p n , so dp n (t)  non-critical messages. In Table 3 The parameters of critical and non-critical messages are  solution. It is obvious that an IoT system having blockchain 798 implementation at any level and in any form decreases the 799 system throughput and also increases the number of mes-800 sages in the system at any specific time. Along with the 801 disadvantages mentioned above, blockchain has many advan-802 tages, such as immutability and the integrity of the untrusted 803 network. Results are obtained 10 times in a scenario by 804 fluctuating the message arrival rate (λ) 300 and increasing the 805 remaining experiment by 300 messages per second to 3000. 806 Results are obtained and depicted in the line chart.

807
In Figure 8, a comparison of packet drop rates is repre-808 sented in the cases of CDC-IoT, DualFog, and the proposed 809 solution. The X-axis represents the message arrival rate per 810 second, and Y-axis denotes the packet drop rate. At an arrival 811 rate of 300 and 600 requests per second, the packet drop rate 812 is 0 for all three architectures. But after the arrival rate of 813 600, CDC-IoT observed a high drop rate. The drop rate of 814 the proposed solution is the lowest compared to CDC-IoT 815 and DualFog. The main reason for the packet drops rate is 816 congestion. It means when a resource is utilized beyond its 817 capacity; extra messages start to drop. In the case of the 818 proposed solution, AP has an unlimited queue length and 819 forwards all messages to FB in the FCFS technique. The 820 proposed solution has the lowest message drop rate. 821 VOLUME 10, 2022 In Figure 10 Cloud resource utilization is depicted in the 841 graph. CDC-IoT utilizes 40% of cloud resources at a message 842 arrival rate of 300. When the message arrival rate is 600 then 843 80% of resources are utilized. After 600 messages CDC-IoT 844 utilizes 100% of its resources. In the case of Dual-Fog, cloud 845 resources are utilized far less than CDC-IoT. 846 At message arrival rate 300 only 10% of cloud resources 847 are utilized at message arrival rate 600, 900, 1200, 1500, 848 1800, 2100, 2400, 2700, and 300 cloud resource is 20%, 849 22%, 25%, 22%, 25%, 22%, 21%, 22%, 22% respectively. 850 In the case of the proposed solution utilization of cloud, 851 resources are less than CDC-IoT but a bit greater than Dual-852 Fog. The reason for fog utilization is due to cloud services 853 of the mining operation. In the proposed solution Blockchain 854 mining is attaining with cloud services i.e., MaaS. 855 Figure 11 compares CDC-IoT, DualFog, and the suggested 856 approach in terms of system reaction time. The X-axis depicts 857 the number of messages arriving each second, while the 858 Y-axis depicts a time in seconds. When the message arrival 859 rate is 300, the reaction time of the CDC-IoT system is 860 virtually zero. The proposed solution is sandwiched between 861 CDC-IoT and DualFog, with a time of 1.1 seconds. Because 862 CDC-IoT sensing devices collect data from the environment 863 and transfer it straight to the fog layer, scheduling is required 864 at the FB in the proposed system. As a result, there may be 865 some delays. The suggested solution's system reaction time 866 is faster than CDC

867
IoT and DualFog at a message arrival rate of 400 to 868 1500 per second. The graph lines of these three solutions 869 are practically parallel after 1500 to 1800 messages per sec-870 ond. In Figure 12, the suggested solutions, CDC-IoT, and 871 DualFog are compared in terms of system throughput. CDC-872 IoT has the highest throughput of the two remaining solu-873 tions. Moreover, the CDC-IoT results are without blockchain 874 implementations. DualFog and the suggested method have 875 almost comparable throughput. The throughput graph of proposed solution is slightly 877 below the DualFog line. When the message arrival rate is 878 300 and 600 per second, the throughput of CDC-IoT is 879 between 300 and 600 per second. When the message arrival 880     the fog and cloud levels, the IoT model is further evaluated 890 and compared with DualFog forhandling critical and non-891 critical requests. Critical messages 20% and non-critical 80% 892 are considered in the first simulation; critical 40% and non-893 critical 60% are considered in the second simulation; critical 894 60% and non-critical 40% are considered in the third simu-895 lation, and critical 80% and non-critical 20% are taken in the 896 fourth simulation. Figure 13 shows the system response time, 897 which clearly shows that the proposed system response time 898 is significantly faster than the DualFog solution when the crit-899 ical messages are 80% or above, simulation 4 demonstrates 900 VOLUME 10, 2022 the Poisson arrival and exponential service time have been 920 adopted in the literature to get an appropriate approximation 921 of real systems. As stated in [58], [59], [60], [61], [63],  It's also difficult to discover a viable method for delivering  In this solution, storage is done at the fog layer, while pro-943 cessing is acquired from the cloud. Blockchain fog storage 944 will minimize latency and also cloud computing is more 945 cost-effective. Another thing is that, because of the requests 946 from several heterogeneous systems, this strategy allows for 947 message scheduling at the fog layer. The fog layer is divided 948 into two halves. For critical messages, the first sub-system 949 will operate as a legacy CDC-IoT, while the second will act as 950 a novel blockchain-based environment for non-critical mes-951 sages. As a result, it can be stated that blockchain incorpora-952 tion with IoT is feasible and should be pursued; the question 953 is how it is managed properly. The architecture presented here 954 serves as a foundation for future Internet developments. This 955 integration will not only inherit the benefits of blockchain but 956 will also have a significant consequence on the effectiveness 957 of life by lowering the energy consumption of massive CDCs. 958 This idea can be implemented in IoT, healthcare, and smart 959 cities in the future to take advantage of blockchain integration 960 with IoT in a smooth way. It is also worth noting that all 961 arriving messages from connected devices in the present sim-962 ulation model follow a Poisson distribution, and the response 963 time of all the nodes in the simulation is expressed as the 964 mean. In actual systems, however, depending on the content 965 and kind of data, arriving requests may fluctuate and follow 966 different patterns. 967 fog-enhanced blockchain-assisted task scheduling,'' Inf. Process