Reinforcement optimization for decentralized service placement policy in IoT‐centric fog environment

A decentralized service placement policy plays a key role in distributed systems, such as fog computing, where sharing workloads fairly among active computing nodes is critical. A decentralized policy is an inherent feature of the service placement process that may improve load balancing among computers and can reduce the latency in many real‐time Internet of Things (IoT) applications. This article proposes reinforcement optimization for a decentralized service placement policy, which attempts to mitigate some of the drawbacks of existing service placement policies. Matching task size with node specifications and the allocation of less popular but time‐sensitive applications in the fog layer are the primary contributions of this study. Extensive experimental comparisons are made between the proposed algorithm and other well‐known algorithms over service latency, network usage, and computing usage using the iFogSim simulator. A microservice‐based application with varying sizes of computing requests are tested experimentally and show that the proposed algorithm effectively serves computing instances that are closer to users, reducing service latency and network usage. Compared to the existing models, the proposed modified algorithm reduces service latency by 24.1%, network usage by 4%, and computing usage by 20%, thus highlighting positive outcomes when using the proposed algorithm for fog analytics in future real‐time IoT applications.


INTRODUCTION
2][3] According to the report of McKinsey Global Institute, 4 the IoT applications will facilitate $11 trillion economy by 2025.Quality assurance in IoT applications is of paramount importance due to the rapidly increasing number of human users and their future service requirements.For the quality assurance of IoT applications, cloud servers were expected to integrate IoT technologies with human users. 2,5,6The cloud-centric IoT network has been designed to alleviate the constraints of IoT devices, which are due to the limitations of computational and memory resources, by providing centralized control of IoT devices. 5,7,8][19][20] Cloud servers and fog networks provide alternative options for IoT edge devices to access computing resources.A fog data manager (FDM) can determine whether the data are executed either in the fog network or cloud servers.The FDM can transmit part of the data to the cloud servers, while the remaining data are retained on the fog network, as discussed by Puliafito. 21Once the data are allocated to the fog network, the placement policy (PP) can optimize the resource allocation within the fog network to maximize the use of computing nodes within the fog network.Fog service orchestrators (FSOs) can also fairly allocate computing resources among the fog nodes to improve the quality of service (QoS), as presented by Baranwal. 22However, both of these methods do not address scalability issues in an IoT network well, and Salaht and Desprez 23 addressed scalability in their fog service placement problem (FSPP).An efficient FSPP is vital to assure the QoS of IoT applications.A failed or suboptimal FSPP can results in delay in fog analytics causing major issues to the real-time IoT applications.
FSPP is important, but its current centralized practice have some disadvantages: (a) increased network overhead due to the periodic communications between the resource broker and fog node; (b) longer computing time due to the increased number of IoT edge devices to control; (c) reduced reliability to a single point of failure (SPOF); (d) management of heterogeneous fog devices; and (e) inherent latency generated by machine communications between brokers and fog devices.However, the decentralized scheduling algorithm (DSA) proposed by Desprez and Salaht 24 relies on the time vector for efficient operation.A poorly managed FSPP can cause real-time IoT applications to fail due to the "induced" high latency. 25his study reinforces the current placement policy FSPP using a proposed new policy to overcome some of aforementioned shortcomings.This study proposes an innovative FSPP that operates in a distributed manner to reduce the induced and inherent latencies in IoT applications that prioritizes delay-sensitive applications to be served with priority placement even with a low popularity rate.The father node, which receives the computing tasks from the end-user nodes, can forward the services or maintain the services if the father nodes are compatible.All tasks are managed locally by the father node and its subordinate nodes without global scheduling.Such an FSPP is more scalable and not affected by the increasing number of IoT edge devices or services.This study also performs several experiments to confirm the above hypothesis.The primary contribution of this study is a more scalable FSPP that also reduces computing requirements while reducing both inherent and induced delays in time-sensitive IoT applications.The new FSPP may limit global communication between fog nodes, therefore not guaranteeing global optimization; however, as the size of the IoT network increases, global optimization is often not necessary. 25,26In this approach, the proposed method places the most popular or delay-sensitive compute tasks closer to the end-user nodes using the hop number as the reference.This method manages the workload for fog nodes to remain sustainable with locally optimized QoS, thereby satisfying the necessary computing requirements of IoT applications in the fog network.The primary objective of this study is to develop the decision criteria for service allocation, including when and where the services are to be allocated among the IoT fog nodes, and associated time-sensitive requirements (either closer or further from the end-user nodes).

RELATED WORKS
Fog networks can use many optimization techniques, including greedy algorithms, heuristics, genetic algorithms, and linear programming.In References 27-31, several aspects of fog resource management are defined, including scheduling, placement, provisioning, allocation, and mapping for clients, virtual machines, services, and resources.][34][35] Table 1 summarizes recent work, including application types (eg, eHealth IoT system, general IoT system, or embedded system) in the column Scope, types of brokers (Broker), proposed algorithms (Alg.), target functions to optimize (Objective functions), components that the optimization algorithm can control to enhance the objective functions (Decision variables), validation tools used to test the algorithms, and types of computing environments (Env.).Khosroabadi and Fotouhi-Ghazvini 5 proposed "a clustering of fog devices and requirement-sensitive services first" (SCATTER) algorithm to allocate the fog-edge border computing resources to delay-sensitive applications but ignores the other tasks in demand, which could be a concern in many real-life applications. 39introduced popularity ranked placement (PRP) based on graph partitions and optimization using genetic algorithms, and showed that PRP yielded improvements compared to the generic genetic algorithm or first fit (FF) algorithm but could still be improved.Morkevicius and Venčkauskas 40 presented two stages of multiobjective optimization that included multiple metrics that we use in this study to evaluate the proposed method: security performance, compute usage performance, and storage utilization.This technique was designed to maintain the QoS level with the minimum usage of available resources.
QoS and energy consumption metrics were used to evaluate the algorithms proposed by Hassan et al 38 ; Kamel 19 ; and Puliafito. 21Those authors attempted to enhance the service placement policy in a cloud/fog environment, ultimately improving QoS in delay-sensitive applications.Hassan and Azizi 38 proposed a MinRE placement policy to enhance QoS and energy consumption in a cloud/fog ecosystem.MinRE consists of two algorithms, MinRes and MinEng, where each focuses on different types of workload.During experimentation, MinRE showed promising results, even with a fixed number of fog nodes, while increasing computing loads.Baranwal and Vidyarthi 36 used distributive fog orchestrator nodes (FONs) to place services on a fog-integrated cloud.The FON, a mediator entity, was proposed by Al-Tarawneh to assign the arrival workload to the fog computational node (FCN).Al-Tarawneh 41 proposed a biobjective placement algorithm to enhance the placement policy for interoperated services in a fog network.That study considered the security requirements and criticality of the application as optimization variables, and improved the satisfaction metrics compared to other policies, including edge-affinity and cloud-only.
Maiti 42 designed a service placement policy to use schedule gaps.Their proposed policy aimed to minimize the makespan to meet the task deadlines with less utilization of communication resources.In Reference 43, an intelligent fog and service placement (IFSP) was proposed to proactively place services on demand using deep reinforcement learning (DRL) hosted in the cloud to predict the system's load expectations with the entire database.The IFSP can thus prepare nodes predictively before bearing workloads.Salimian 37 proposed autonomous IoT service placement to reduce the execution costs of a distributed fog system using the gray wolf optimization (GWO) scheme, which outperformed comparable policies in finding suitable fog nodes to allocate computations.For heterogeneous cloud/fog environments, 44 presented a heterogeneous shortest module first (HSMF) placement policy.The HSMF was based on finding the shortest module to serve first, which yielded improved performance compared to the other policies.Wang 38 introduced a job allocation methodology for interdependent services in a fog network, where interdependent jobs rely on internode data communication and were described using a directed acyclic graph (DAG).The Wang model 38 was limited because it did not consider the deadline constraint and workflow execution.A linear approach (first comes, first serviced) has been widely used, but task completion in ascending order is more time-efficient. 34However, sorting can be resource-intensive in terms of time and computing.
The decentralized service provisioning introduced by Guerrero 45 produced promising outcomes, such that all latencies in data transmission, decision processing, and return response were reduced, as well as achieving fair load balancing.However, this system still has a challenge due to its high running cost.Random service allocation was discussed by Souza 46 but resulted in a high service delay due to poor load balancing.Huang 47 proposed an energy-efficient approach to the idea of co-locating service placement, which was adequate for a small network but achieved poor service placement in a larger network.A similar approach by Wang et al 48 reduced execution costs by placing predictive modeling tasks.The proposed solution performed well, but the cost of the system was high, making it unaffordable to a small company.Taneja and Davy 49 proposed a resource-aware service placement solution, a good approach for QoS optimization, that first considered the highest-demand application tasks.Thus, the mechanism resulted in a swamped network with idle and waiting states with low-capacity devices/nodes.

Architecture
In real applications, a fog network is an extension of a cloud network.The extension of the decentralized, remote distribution of the cloud network can be considered a fog network.The computing nodes within the fog network are equipped with limited storage capacity and computing power for host instances, and can thus be considered cloudlets. 50Thus, a resource management policy for the IoT network can determine where and when to place computing instances among the different layers of computing nodes (eg, fog or cloud).This article proposes an innovative service allocation architecture that alleviates the drawbacks of FSPP, particularly for time-sensitive applications.
Given the three layers of the IoT network (cloud, fog, and edge) as shown in Figure 1, the top layer is the cloud layer that contains the primary cloud servers.The access layer is the edge layer, where end devices manage requests for IoT applications.Edge devices can include computers, smart cars, sensors, and smart homes. 51,52The fog nodes connect to both the edge devices and cloud servers.This study assumes that all applications in an IoT network use microservices. 53These applications were configured as a group of stateless and trivial services.These small services complete a complex task once executed in a sequence.For example, app1 requires s 1 , s 4 , and s 6 to perform its complex task, while app 2 requires s 1 , s 2 , s 3 , and s 5 , where the system consists of N services, as shown in Figure 2.Both applications must complete a specific number of jumps to perform app 1 and app 2 .Thus, each computing node can be scaled up and down in their instances to improve the QoS of the distributed fog nodes.The scaling process can use service codes from the cloud servers.
This article proposes an optimization of service placement by (1) allocating the most demanded services and all time-sensitive applications in a particular area in the fog nodes that are closer to the clients (edge); (2) migrating the services that are not used regularly to reserve the available resources for other priority services; and (3) managing service allocations to prevent system overloads.For example, if a large computing task is allocated to a less powerful device, an overload will occur in the system.Due to resource limitations in fog nodes, the service placement policy must select services that are to be migrated.The proposed algorithm allocates priority services to the nearest nodes in the shortest path and migrates the lowest nonsensitive requests to the upper levels away from the users and closer to the cloud.
System latency is inherent in all IoT applications.Although the service placement policy can reduce latency in some fog applications, a delay-sensitive application demands further reduced latency to perform adequately in a time-critical application.For example, a device for a stroke patient must respond within near-zero seconds, where any delay in the reporting system can have marked consequences for the patient. 54The metadata of service requests must be evaluated in priority assignment; thus, such critical tasks can be allocated near edge nodes to support real-time requirements.
Many IoT applications perform interrelated services, where the cloud server becomes essential as a long-term solution.The migration of such services along the shortest path to the cloud is essential.The migration of some services can increase the total execution time (and thus latency) if some essential services do not migrate through the shortest path. 27For example, an algorithm finds a service S x with the highest demand for device D 1 .Unfortunately, due to the limitation of D ′ 1 s resources, s 2 , which is selected with the lowest popularity in D 1 must migrate to neighboring devices as shown in Figure 3.Although D 3 has a short distance from the source device, the number of hops increases by two for D 2 , which is located on the shortest path to the cloud.To accomplish this task, s 4 was required.

F I G U R E 3 Example of service migration within different paths
Some services are in high demand (ie, popular), while others are in low demand.The popularity rule works by migrating high-demand services to fog nodes that are closer to the client (edge), while other low-demand services are allocated to the upper nodes with the shortest path to the cloud servers. 3he interoperated service is where a clump of semi-related microservices is combined to accomplish a complex task.Thus, it is critical to migrate all interoperated services (if possible) if one of them must be migrated; this action tends to minimize the number of hops. Figure 4 shows the idea of partially migrating the interoperated services.We assume that the service execution flow for an application is s 1 → s 2 → s 3 → s 4 → s 5 .Due to the limitations of D 1 's computing resources, s 3 , which has the lowest request rate in D 1 , must be migrated to D 2 , which resides at the upper level closer to the cloud and away from the edge.Two additional hops will be added to the application if the placement management system (PMS) does not migrate to the next interoperated services, S 4 and S 5 .Thus, it is essential to verify the migration of S n+1 and higher, and keep S n-1 at the same node.If we assume that S n is the migrated service, as shown in Equation ( 1), the PMS must maintain the migration process for the (n + 1)th interoperated service along the shortest path to the cloud while keeping the (n−1)th in the initial node D 1 : ( This strategy must be activated if the initial node has limited resources.The computing node uses a decentralized service broker in the proposed system, which has proven beneficial against a centralized management system. 55 decentralized broker is used to implement the proposed strategy.The modeling and characterization parameters were obtained from Reference 3 but with modifications.The modification is made using the service placement request manager (SPRM).A matching code is used in the SPRM to add more restrictions to accept the tasks or migrate them to the higher layer.Therefore, the computing nodes accept workloads by matching their sizes with node specifications.Conversely, Figure 5 shows the proposed broker, which keeps the remaining components of the broker having similar functions as service manager (SM), service usage monitor (SUM), and service popularity monitor (SPM).Fog clients must be connected to one leaf device or gateway in the fog network to start using available services.Each time the client requests a specific service, a service allocation request (SAR) is generated to obtain permission to reserve the computing resources.The SPRM decides to accept the allocation of this service or forward the SAR to the next upper fog device (see Figures 3 and 4).The SPRM decides after analyzing the local device information gathered from the SPM and SUM.Although the SUM aims to collect internal data about fog devices, the SPM is designed to measure the service request rate, which the SPRM uses in its calculations.Each node either decides to host the services or migrates them to the next available node in the upper layer.

System model
In the proposed model, which follows the principles of FSPP, all applications requested by a group of clients, C n , are initially allocated to cloud servers, S cloud .Each application comprises a set of (interrelated) service units.Therefore, a sequence of service units must be executed to perform a specific application.Applications in the cloud are called by clients in the lower layer (closer to the edge) with a group of interconnected fog devices D in between.These fog nodes have constrained but available processing power that can complete the sequence of service units without relying on cloud servers.SP Cloud S is a term used to define the shortest path between service tasks and the cloud with the minimum number of hops.The father (D 1 ) of the device defines the first device that receives service requests.
The decentralized approach allocates services to local (neighboring) fog devices.Various instances (S y x , where x is the service number and y is the code of the device that hosts the services) are allocated across the fog nodes.Thus, considering a given instance, we can formulate the relation as a many-to-one relationship alloc ∶ To complete an application, every client C x must be connected to the system through a leaf device.The leaf device can communicate with one or more devices simultaneously.Thus, the relationship in this model was defined as a many-to-one relationship conn.
for each client must be considered in this study to categorize services.Each device D i connected to the system must analyze its behavior by monitoring the request rate that it receives for each task.To calculate the request rate for D x , for example, we must sum all the requests of clients who are in the range covering D x as follows: ∀C n ∈ The coverage area of D i . (2) To determine the performance of each device in the system, we consider the computational capacity of a fog device.Therefore, the resource capacity is introduced as , which is constant for each device and where R is the power consumption of Di depending on the allocation process in each device, which must be variable.Therefore, it is essential to calculate the total resource usage R utz D i for each computing node.The total resource usage can be calculated as follows:

Optimization model
The proposed algorithm allocates the most popular (in-demand) computing loads closer to the client layer and allows all nodes to accept computer loads if resources are available with the correct specifications.Thus, the service request rate is part of the acceptance metric in the SPRM module.The decision for each fog node is to locally analyze the service request rate prior to migrating less popular services to the cloud.The heavy tasks that overload the local nodes also migrate to the upper level. 56Notes that heavier tasks should be kept closer to the cloud provider.In both cases, the interoperated services migrated to the cloud once classified.The migration of the interoperated services with the undesirable service decreases the number of unwanted hops in the network, as previously discussed in reference to Figure 4. Table 2 summaries the functions and variables that are used in the proposed model.Algorithm 1 shows the pseudocode for the proposed enhanced service placement policy.The placement algorithm is invoked when a particular service cannot serve appropriately with the local fog nodes and/or when the available capacity of a fog device is inadequate to satisfy the maximum service requirements.(line 1).The latter condition ensures that all fog nodes in the proposed policy have sufficient capacity to run the most popular services.If these criteria are met, the .The father device is the closest computing node to the client's gadget.Thus, it is critical to maintain the highest demand instances in a leaf device. 57dditionally, once the father device is selected, the first-child device D Child 1 must be selected (line 4) by identifying the shortest path to the cloud (line 3).Thus, the first-child device D Child 1 receives SAR messages if D i begins straggling.The service placement request manager (SPRM) in the child device decides to either host the service or migrate it again by generating another SAR to its own child while recalculating the shortest path.The decision of the child depends on the popularity of the service in D Child 1 .Typically, SPRM gathers essential data by SUM and SPM, where both are located within the same local broker.The reinforcement optimization for a decentralized service placement policy (RODSPP) algorithm also ignores the remaining child in the route to the cloud, where each fog node recomputes the shortest path once the previous criteria are satisfied.This strategy reduces the dependency on operational conditions for the remaining distant fog nodes.
Because this algorithm aims to improve service availability in the fog nodes, the system downloads the services from the cloud in some cases.To download service S y x in the candidate fog device D i (line 6), the candidate node must have adequate resources to serve the requested tasks; the device overload must also be within the acceptable threshold, and the tasks must be recognized as part of delay-sensitive applications (line 5).Eventually, the algorithm uniquely guarantees the maintenance of the overload of all computing nodes, while the POP algorithm focuses only on the guaranteed availability of services at the nodes. 35The proposed algorithm then installs services with the highest service rate (line 8); otherwise, the candidate service is migrated to the upper level (line 17).The migration process extends the computing capacity by alleviating current loads.If the service is recognized as a high priority, the interoperated services for the lowest service rate must be migrated together (line 11).To create the required computation space to perform the top services, the number of spaces must be identified (line 9).The placement algorithm begins to sequentially migrate the lowest services and its interoperated services to its child (lines 12-14).Thus, the node begins by sending SAR D Child S x to its child.Every child identifies his or her own child to communicate directly.Once the migrated services are deallocated from the father device, the required services are downloaded (line 15).

Algorithm 1. Enhancement of placement optimization policy algorithm
We now consider that the case study device D i is currently allocated s 1 , s 2 , and s 4 in Figure 4. Due to emerging popular services and limited resources, SPRM may decide to migrate s 2 as the lowest service usage.This action had several consequences.First, D 1 is assigned as the father device, and D 2 is assigned as the child, where the shortest route D 1 → D 2 → S Cloud has two hops, and the other route has one more step D 1 → D 3 → D 2 → S Cloud .Second, the most popular service requirements must be less than the currently available computing resources, and the node configurations must satisfy computing requirements; the latter condition avoids overloading the computing nodes.Then, we are obligated to migrate s 2 and its interoperated services s 4 , and the first migration process occurred for s 2 , followed by s 4 .Finally, the required service triggers the download, while the migrated services commence finding another child host in the shortest path.
Algorithm 1 shows the pseudocode of the proposed resource optimization algorithm.The request for migration is activated only when the requested service exceeds the currently available resources.We have provided a service for data classification using a lightweight module. 56The service allocation request is sent to the gateway and then onto the fog layer.In this layer, the controller estimates the service requirements and sorts the devices accordingly.Thus, time and complexity are limited in sorting and job allocation.Devices that have the required capacity will be identified and allocated for computing in a predictive manner; thus, the tasks will be assigned to those nodes that have the capacity and are available for operation.Also, complex tasks will be assigned to nodes that are not busy and have sufficient power to perform effectively.Simple tasks are thus assigned to nodes that are busy and have less capacity.This approach minimizes latency and power consumption, and a reduction in power consumption generally reduces overall operational costs.

Evaluation
We used iFogSim simulator 58 for the microservice-based simulation.The module placement class has been modified to evaluate the proposed model.This evaluation compared the POP 5 with the edge based on iFogSim's built-in placement policy.Different scenarios were considered to evaluate the proposed algorithm by varying the parameters of the number of applications, the number of fog devices, and the number of users/clients.The configurations of the devices in the simulation environment are shown in Table 3, and the experiments followed the same configuration parameters in the POP study. 45The experiments used a tree-based network topology to manipulate the number of devices in a system.Each fog device interacted with another fog device at the next level via the shortest path to the cloud.This forwarding process represents the migration activity for the lowest-priority task.For simplicity, the network device's behavior was not changed and was fixed with the shortest path once identified.This proposal identifies the number of children at each level, as shown in Figure 6.
As discussed in Section 4.1, cloud servers are assumed to provide unlimited computational resources.The memory in fog devices was sufficiently large in these experiments; thus, we can ignore memory's immediate influence, which is the current trend in fog devices: memory is rarely a limitation. 59Although computational capacity is the prime evaluation vector, network bandwidth was also considered to affect migration, which relies on the exchange of data between devices.As the number of migrations increased, the number of hops also increased.Thus, we considered the number of hops as the metric to evaluate network usage.
Microservice-based applications are common in IoT domains.In microservice-based applications, the number of service placement requests describes service popularity.System latency is a critical factor for real-time services because delays may not be tolerated in some cases.The case considered in these experiments was an online store application, as shown in Figure 7.A similar benchmarking experiment is discussed in Reference 45.
This microservice-based online store application is widely used in IoT modeling and is called a shock shop. 1 The configurations for this application in the proposed container followed the benchmark. 45

Experimental results
The experimental setup for the proposed system followed existing recommendations.A different set of models was used in the experiment to compare and evaluate performance.The execution of simulation-based applications varies from machine to machine, depending on its scalability level.The details of the device model, operating system (OS), random access memory (RAM), hard disk drive (HDD), and processors that participated in the experiment are shown in Table 4. CloudSim 60 is a requirement for iFogSim for cloud-based operations, and datacenter is managed by this tool.Java and JavaScript object notation (JSON) used to program the proposed algorithm, while common math is the library used for complex mathematical computations in the simulations.
The results of the experimental evaluation are presented in terms of CPU usage, system latency, and network usage.The equations used to calculate these two metrics were programmed in the simulator.By analyzing the iFogSim source code, we obtained the equation used to calculate them, as shown in Equations ( 4) and ( 5), respectively: where T ltsy D x →D y is the time consumed to migrate the request from one device to another and Req Size is the size of the request that travels through the network.Network usage is the amount of data transferred from the original device or the loaded device to the destination device, which enriches free resources at a specific time.
An increase in the number of devices leads to more complex network usage scenarios, which can create network congestion, which indicates low system performance.A network usage comparison indicates the low or high performance of a system.Compared to the edge policy, the proposed solution reduces network usage by executing most of the tasks System latency is the time required to perform a set of interoperated services to achieve the required application.iFogSim measures system latency by determining the average time required to execute the complete path of the interoperated services.Latency is the most important characteristic of the computing paradigm: the lower the system latency is, the more reliable the system.Equation 6 was used to calculate the system latency ( Lty sys ) as configured in the simulation tool: where T Srt n and T Fnl n are the start and final times required by the nth service, respectively, and Req u is the total number of requests in the interoperated service list.
The following figures show a comparison of the three algorithms.The results of the proposed algorithm are labeled as RODSPP; those for Guerrero and Lera 45 are labeled as POP; and the edge is the label for the base policy of iFogSim.Figures 8 to 10 include two subfigures that show the effects of variation in the setting of execution: (A) variations in the number of users connected to one leaf device or gateway to examine varying levels of workloads; and (B) variations in the number of devices in the fog environment to study the influence of the route length on the network performance.
Figure 8 shows the hop count outcomes and plots the weighted average hope count proposed in the POP manuscript, 45 representing how the most popular services are closer to customers.Figure 9 shows the latency results for a representative loop of the application.At their highest rates, the experiment configured most of the parameters, such as accounts, orders, frontend, and edges.The simulator calculates the time taken by the edge server to complete the requested tasks.
CPU usage is an important performance metric of a system because the processing quality of a system in a scalable manner is measured in terms of the CPU.If CPU usage is too high, delays occur during processing.
The results of CPU usage, UCPU, are determined by the Equation ( 6) as follow: F I G U R E 7 Application edges for online store-based case study where T b is the busy task rate, T i is the idle task rate, R t is the average tuple time, T mips is the total number of mips (million instructions per second) in the host, and F mips is the final mips in the control of the CPU.
Figure 10 shows the CPU usage of the devices by varying the number of users in each device.The experimental setup was configured as follows: two applications, up to five users per gateway, one child per device, and two fog devices per level.This setup is similar to the experimental benchmarking setup.

DISCUSSION
System latency is an important performance metric in fog computing.The weighted average hops effectively measures the proximity between the services and users, therefore providing some sense of system complexity.Thus, we used both metrics to answer the first research question.The series labeled edge, POP, and RODSPP in Figure 8 were thus analyzed.
In Figure 8A, the graph shows a marked increase in the number of hops for all three approaches when the number of users increases, implying that the system would slow down once the number of users increases, and the resources conflict.The weighted average hops indicated that RODSPP consumed 4% more hops than POP and 23.1% fewer hops than edges.The increase in hops in the RODSPP was due to migrating the interoperated services, which have low request rates and matching the size of the task with the node resources to avoid overload.RODSPP prevented overload for the computing nodes in all layers by migrating excessive tasks from the overloaded ones.POP and edge were not affected by the changes in the number of fog devices; RODSPP tended to migrate more services to the upper levels closer to the cloud.Due to the addition of two more service categories to activate the RODSPP algorithm, such as delay-sensitive applications, even with a low request rate, the migration process increased with an increasing number of fog levels in the system, as shown in Figure 8B.Therefore, RODSPP did not decrease the number of hops while maintaining the most usable and delay-sensitive services in the edge-fog network.This behavior is acceptable if we try to solve many issues with limited resources in leaf nodes.In Figure 9, after we split the tasks into high and low request rates, Figure 9A shows that there has been a marked rise in the time latency incurred by the highest popularity applications.What is striking in the chart is the outperformance of RODSPP by 24.1%, which is due to matching the workloads with F I G U R E 8 Hops count with different situations.Experiment with two applications, two users, and two levels of fog devices: (A) changing the number of devices associated with the edge device; and (B) changing the number of proposed fog levels the capability of the computing nodes.Although RODSPP recorded a noticeable increase in hops, it achieved fair results in the overall scheme of the performance.
POP ignores low-requested services without considering their sensitivities.We added a delay-sensitive application with a low request rate to the proposed experiment.RODSPP allocates low-popularity applications on a leaf device if it is a delay-sensitive application.To answer the second research question, we consider Figure 9B, which shows the performance of the POP and RODSPP for applications with low popularity but high time sensitivity.The chart shows the comparable behaviors of both the RODSPP and POP policies in non-time-sensitivity applications.The chart shows that there has been a sharp decline in system latency for RODSPP in delay-sensitive applications.Thus, RODSPP is recognized as a valid policy for delay-sensitive applications even with low popularity.Generally, even though the system places all services at the border in the case of one user, the gateway still engages the cloud to accomplish complex tasks in real life.The third question in this study addresses the performance of RODSPP, among other models, in CPU, network usage, and system latency.The system latency parameter has already been discussed in the second question.The RODSPP showed F I G U R E 9 Service latency in different situations.Experiment with two applications, two users, and two levels of fog devices: (A) changing the number of devices associated with the edge device; and (B) changing the number of proposed fog levels outstanding outcomes for delay-sensitive applications with low request rates, as shown in Figure 9. Thus, RODSPP can be highly recommended for time-sensitive applications.
Figure 10 shows the relation between the CPU usage in different layers and the network usage.Figure 10A shows the CPU usage of the father nodes in the proposed algorithm, which outperformed POP by matching the workloads with the available resources.This feature has improved the use of border CPUs.The proposed algorithm tends to decrease the load of children's CPUs once a new layer appears, which increases network usage.Although RODSPP consumes 4.5% more network bandwidth than POP, it decreases all fog resource usage by 20%.The primary contribution of this study was to synthesize well-disciplined resource allocation approaches using them in local optimization through a divide-and-conquer approach in a carefully articulated realistic IoT fog networking environment.This study demonstrates successful IoT fog resource allocations in terms of controlled response time and constrained computing resource usage, thus providing important insights and guidelines for the community to refer to and seek further enhancements in real-time IoT fog applications.CONCLUSION AND FUTURE WORK

Conclusion
The span of IoT devices is growing day by day, generating large amounts of data.However, the cloud cannot manage and process an increasing number of IoT devices for real-time processing, which requires low latency and reduced resource consumption due to its centralized and distant architecture.Server mobility and decentralization are requirements for IoT devices for real-time data processing.A fog computing paradigm is thus proposed in this study to meet the requirements of future IoT networks.In this regard, this research proposed reinforcement optimization for a decentralized service placement policy (RODSPP), which attempts to mitigate the drawbacks of existing placement policies by decentralizing FSPP intelligently.To verify the performance of the proposed RODSPP, extensive experimental comparisons were made against the other well-known algorithms including edge and POP using the evaluation parameters of service latency, network usage and computing usage.The experimental analysis showed that the proposed load-balancing algorithm better utilized the local fog computing resources and supported well the real-time performance requirements of the IoT applications.

Future work
Although the proposed algorithm (RODSPP) achieved the improved performance within the parameters considered in this study, we plan to improve upon these results further by considering more performance dimensions relevant to the IoT applications in the industry.Thus, we aim to support the real-time industry IoT application with the proposed innovative FSPP scheme.

F I G U R E 4
Example of interoperated service migration within the shortest path F I G U R E 5 Decentralized service placement, the broker

F I G U R E 6
Proposed network    closer to the clients and by a well-formed job allocation mechanism at the fog layer.This strategy minimizes cloud usage, which eliminates the use of data transfer/communication networks by default.

F
I G U R E 10 CPU usage of the devices with regard to their topology distribution.Experiment with two applications, two users, and two levels of fog devices: (A) CPU performance with the POP algorithm; and (B) CPU performance with the RODSPP algorithm

6
Summary of approaches to service placement TA B L E 1

TA B L E 2
Summary of the functions and variables used in the proposed model )Function the service which record the lowest request rate in device D i DAS (S x ) Function that return true if the service is delay-sensitive application.nDSA (S x ) Function that return the list of non-delay-sensitive application.Migrate (S y x ) Function that deactivate the instance S x or several instances in D i and send SAR request to next device to start migration process gateway or leaf device D i is the father of route D father (line 2)