Abstract
A huge amount of smart devices which have capacity of computing, storage, and communication to each other brings forth fog computing paradigm. Fog computing is a model in which the system tries to push data processing from cloud servers to “near” IoT devices in order to reduce latency time. The execution orderings and the deployed places of services make significant effect on the overall response time of an application. Beside new research directions in fog computing, e.g., fog-cloud collaboration, service scalability, fog scalability, mobile fog computing, fog federation, trade-off between energy consumption and communication efficiency, duration of storing data locally, storage security and communication security, and semantic-aware fog computing, the service deployment problem is one of the attractive research fields of fog computing. The service deployment is a multiobjective optimization problem; there are so many proposed solutions for various targets, such as response time, communication cost, and energy consumption. In this paper, we focus on the optimization problem which minimizes the overall response time of an application with awareness of network usage and server usage. Then, we have conducted experiments on two service deployment strategies, called cloudy and foggy strategies. We analyze numerically the overall response time, network usage, and server usage of those two strategies in order to prove the effectiveness of our proposed foggy service deployment strategy.
1. Introduction
Cloud computing is a suitable computing model for all users to deploy their applications into their customers because there is no need for investing much on physical equipment and there is no limitation on customers’ geographic locations. End users are able to rent cloud services with various configurations (e.g., storage, computing, and cost); hence, there is no limitation on applications’ processing because service providers will expand logical or physical servers according to their customers’ requirements. Therefore, communication cost of applications from end-user devices to servers plays an important role in the response time of an application. Nowadays, the amazingly fast development of devices transforms from “thin sensors” to “smart devices”. “Thin devices” are sensors which only detect or measure the changes of conditional environment. “Smart devices” are devices which have additional features, such as computational, storage, and networking resources. When devices have effective communication methods to each other, they are able to join owned Edge computing networks in order to share computing, storage ability. Edge computing networks integrate with cloud computing into fog computing.
Fog computing is in the beginning phase of its life time. Firstly, F. Bonomi et al. give a first definition on fog computing with three characteristics (e.g., highly virtualized, resided between IoT devices and cloud, and not exclusively located at the edge) [1]. Then, L. M. Vaquero et al. also state another definition on fog computing as networks consisted of heterogeneous, ubiquitous, and decentralized devices connection, without third party invention, and running in a sand-boxed environment [2]. When National Institute of Standards and Technology (NIST) releases an official definition of the fog computing in [3] and fog computing conceptual model in [4], there are many surveys [5, 6] on fog computing and similar technologies (e.g., mobile cloud computing, Edge computing, and mobile edge computing) in order to find out fog computing characteristics and problems deeply. Many works have been done to quantify the layer-based concept of fog architecture, as three layers [7, 8], four layers [9], or five layers [10] of the fog architecture. Because fog computing is formed from the combination of cloud computing and Edge computing, fog computing makes use of advantages of two paradigms in order to overcome drawbacks of those. Fog computing utilizes its owned Edge computing networks in order to push data processing tasks totally or partially from cloudy-level servers to smart devices in the middle layer, i.e., fog devices. If an application requires computing ability more than an Edge computing network’s ability, this Edge computing network will push data processing tasks totally or partially to other fit Edge computing networks or to cloudy-level servers in order to not exceed application’s deadline. Therefore, fog computing is appropriate for applications which are not only processed on the middle computing networks to meet low latency requirement but also processed on cloudy-level for complex, difficult requirements. Therefore, others try to prove that fog computing and its characteristics are effective on many specified applications, e.g., improving healthcare systems and their performance [11–13], vehicular networks and road safety [14, 15], provisioning 5G mobile networks [16, 17], surveillance video stream processing [18], and saving energy in cloud computing [19]. Finally, others focus on specified problems in fog computing environment, e.g., survey on security issues [20, 21], building security schema [22, 23], and building simulation framework named iFogSim [24] and MyiFogSim [25].
An application’s service execution plans have a significant effect on overall processing of this application. There are several optimization solutions for service deployment problem, each of them focuses on different expected target variables, e.g., time (computation time, communication time, deadline), data (data size, data flow), cost (networking cost, deployment cost, execution cost), and energy consumption.
In this paper, we focus on optimization solutions for minimizing overall response time of an application. Our solution is based on checking status of services and fog devices on real-time for finding best deployments. Our work considers the application which is regulated services’ execution priority. The main contribution of our work is that we combine three components (response time, network congestion, and server usage) into one objective function. The best service deployment, we proposed, is an execution plan which has trade-off among minimizing application’s response time, minimizing network congestion, and minimizing cloud layer’s server usage. Then, we do six experiments on characteristics: application type and the number of services for two types of service deployment policy, called cloudy and foggy strategies. Basing on two metrics, overall response time and network congestion, we do compare cloudy to foggy strategies and give analytic on the results for proofing our effective method.
The remaining of this paper is organized as follows: after related work in Section 2 and preliminaries in Section 3, we formulate and describe by algorithms our proposed optimization strategy on resource provisioning on fog landscapes in Section 4. Finally, we explain and analyze our experimental results in Section 5 and present conclusions and future research in Section 6.
2. Related Work
Service Deployment Optimization is a classical problem in computer science. This is a multiobjective optimization without perfect solutions. There are several optimization solutions for service deployment problem, each of them focusing on different expected target variables, e.g., time (computation time, communication time, deadline), data (data size, data flow), cost (networking cost, deployment cost, execution cost), and energy consumption.
O. Skarlat et al. in [26] try to find solution for maximizing the number of services deployed on fog devices. Their research focuses on Quality of Service (application response times). Therefore, the main idea of their solution is maximizing the utilization of existing resources on the fog landscape. Each service will be executed on a device (current fog colony, or neighbour fog colony, or cloud server) if capacities of this device are greater or equal than this service’s demands and estimated execution time is less than the application’s deadline. Then, authors improve their work by applying heuristics to solve their fog Service Placement Problem in [27]. First, the system finds a device which fits for a service’s execution. Then, they swap services placed on near fog devices in order to reduce their transfer time. Authors assume that each service of an application can be executed independently. It is NOT realistic, because the output of a service sometimes is used as the input data of other services. Therefore, the priority of service executing should be considered conceptually.
N. Mostafa et al. in [28] utilize Fog-to-Fog communication and historical executions in order to minimize delay in IoT environment. Authors propose a new algorithm called Fog Resource Selection which is introduced as a run-time prediction for resource selection. Then, they implement this proposed algorithm as the Fog Resource Selection (FResS) module in the fog layer to manage requests from IoT devices towards fog entities. Every request from IoT devices will be sent to FResS module. FResS algorithm is executed in FResS module through two phases. Firstly, FResS module makes prediction on execution cost, required resources based on historical executions. Then, FResS module queries a list of current available resources in order to make prediction on finding the best resource(s) for execution. To reduce prediction cost on FResS module, results of every execution are stored as an execution history log file and are subsequently utilized for mining, discovering knowledge, and updating stored knowledge. They use Artificial Neural Networks (ANNs) as a learning-based method for their system, because ANNs can work with such very large number of resources on fog/cloud computing. The more the number of historical executions, the more the accuracy of predictions. The prediction results are stored in a separate database called the Prediction Model Databases. When a new task appears, the prediction model database is searched locally for sending the result which is an already deployed similar task. After a task is completed, the parameters are stored in the prediction model database for future executions. If not, Fog-to-Fog communication will take place to execute the task. The more the number of historical executions, the faster the predictions.
L. Liu et al. in [29] focus on computation offloading problem in mobile cloud computing, an instance of fog computing paradigm. Mobile Cloud Computing can provide computing resources at the Edge computing networks which is made from mobile devices. Sharing computing and storage capacity in mobile cloud computing brings executing location more closer to the mobile devices. They find that the mobile devices can offload its data or computational expensive tasks to the fog node within its proximity, instead of distant cloud. The most important characteristic of mobile devices is limited energy. However, it sometimes incurs additional delay and generates related cost for enjoying the cloud service. For example, minimizing the delay time by executing close to source mobile devices can be applied by running the services at the local Edge computing networks. On the other side, running too many services locally may take large amount of energy of the mobile devices. The payment cost of users will go down if their application utilizes the resources of Edge computing networks. Therefore, authors address service provisioning as energy consumption, Delay and Payment (E&D&P) optimization problem which is the trade-off among energy consumption, delay performance, and payment cost when deploying services. They propose Interior Point Method (IPM) for transforming multiobjective optimization to single objective optimization by finding the optimal offloading probability and transmit power for each mobile device.
J. Zhang et al. [30] consider fog devices as smart mobile devices (SMDs) which have limited computation resources (e.g., central process unit (CPU) frequency and memory) and battery lifetime. SMDs connect to the cloud sever which has higher computation capacity and storage in order to have capacity on executing computing-intensive applications which require higher computing capacity and more energy than traditional applications on SMDs. It comes into being mobile cloud computing (MCC). As the enormous popularity with the emerging of mobile technologies like Internet of Things (IoTs) and wearable devices and new architectures and key technologies for 5G networks, mobile edge computing (MEC) is presented as a platform for relocating the cloud computation resource close to SMDs because the cloud severs are spatially far from SMDs, which causes high transmission latency and obstructs the latency-sensitive applications. Therefore, computing on SMDs causes high energy cost with the limited battery lifetime. Therefore, authors give definition on the weighting factors of energy consumption and latency in order to consider trade-off of them in making efficient offloading decisions in MEC Networks. Authors focus on finding the solution which optimizes local computing frequency scheduling, channel allocation, power allocation, and computation offloading.
Y. Xiao et al. in [31] consider fog computing as a wireless network-supported system. Fog nodes can offload part or all the workload from the cloud data centers in order to improve the quality-of-experience (QoE) of users. Therefore, authors focus on the workload offloading problem for fog computing networks. QoE is introduced recently in [32] as one of the main guiding paradigms for service quality of the cloud computing networks. In fog computing, authors consider and investigate the relationship between two performance metrics: the users’ QoE and the fog nodes’ power efficiency. Authors propose a novel cooperation strategy referred to as offload forwarding, which describes how each fog node can forward part or all of its unprocessed workload to its neighbouring fog nodes instead of always sending the request to and receiving the returned result from cloud data centers. They use a given power efficiency constraint in order to help fog nodes deciding the optimal partitions of workload to be forwarded to other fog nodes. When investigating the trade-off between the users’ QoE and the fog nodes’ power efficiency, authors propose a distributed alternating direction method of multipliers (ADMM) to approach the global optimal workload allocation.
In our work, we try to make an execution plan which is aware of three issues (application’s response time, network congestion, and server usage). We minimize the application’s response time because the minimum application’s response time indicates the deploying services on devices are a good strategy with low latency. The communication time which is used for sending and receiving date among devices, plays an important role in total response time of an application. Other proposed methods try to deploying service near devices which send the data for minimizing the overall response time of an application. Therefore, the state of devices near deployment process is unavailable. The second considered issue is minimizing the amount of data which is sent and received on the network environment. The final considered issue is server usage. The service usage is computed based on the amount of cloud layer’s server usage for execution application. It means the cost which a user has to charge when using utilities of an application. Therefore, our proposed method is minimizing the server usage parameter in order to reduce overall cost of an application. So, we combine three components (response time, network congestion, and server usage) into one objective function. The best service deployment, we proposed, is an execution plan which has trade-off among minimizing application’s response time, minimizing network congestion, and minimizing cloud layer’s server usage.
3. Preliminaries
3.1. Service and Application
In this work, we define a service as a computing function of an application. Each service has three basic components, input, processing, and output. In Figure 1, there are many complex services which are made from ordered list of services. We assume that a service is an undividable processing unit. It means that a service has to be deployed only on a single device. In practice, we model a service as a 4-tuple, ((), (,), (,), and (,)), described as follows:(i)() is content of service , a set of instructions which have to be executed on a single device, measured on mega-instruction (MI);(ii)(,) is the demand on RAM (memory) of service , measured on megabyte (MB);(iii)(,) is the demand on Storage of service , measured on megabyte (MB);(iv)(,) is the demand on Type of service . This value indicates the type of device where the service can be executed.
Sometimes, the output of a service is used as input of other services. Therefore, we regulate the executing priority between two services. Services having relationship together create a string of services. Relationship of each pair of service and is one of three types, including the following:(i)Service executes after service .(ii)Service will execute before service .(iii)There is no rule on execution order between service and service .
Figure 2 shows us three types of a service string. They are sequence, parallel, and heterogeneous. In the top section of Figure 2, a set of five dotted services is sequence type; they will be executed in sequence. In the left side of Figure 2, there is a set of five dashed downward diagonal services; they will be executed parallelly with each other. Finally, a list of eight light upward diagonal services in the Right-Bottom side of Figure 2 is of heterogeneous type; it is executed complexly based on its regulated execution orders. For example, in the bottom-right section of Figure 2, will be ready to execute if service and service finish their execution already.
At one moment, every service has to get only one state. We define two functions in order to navigate to a service based on its Service Relationships. () is a set of services which have to be executed before , and () is a set of services which can be deployed only if have already been executed. When a service changes its state, it will be able to cause state changes of related services. List of states of a service is described follows:(i)Waiting: when there exists at least one service in the set of () services which have not been executed yet,(ii)Ready: when all services of the set of () services have already been executed, or there do not exist services which have to execute before ,(iii)Executing: when service starts executing on its hosting device,(iv)Executed: when service finishes executing on its hosting device,(v)Released: when service starts releasing resources on its hosting device.
For example in Figure 2, service 2 and service 5 are in the ready status, which means they are ready to execute when service 1 is executed completely. We do not define execution order between service 2 and service 4. This means that service 2 is able to be executed before or after service 4.
An application is a list of service strings. An application is asked to be executed from a specific source device and assigned to send returned result to a specific destination device. We define an application as a 4-tuple, (, , , ), where(i): a device from which such an application sends the request,(ii): a device which will receive the returned result of the considering application,(iii): a set of services of the application,(iv): a set of 2-tuple service relationships, (, ), describing the executing priority between each two services. can be deployed only if have already been executed when there exists a relationship (, ).
3.2. Fog Node Architecture System
This paper uses the architecture of fog computing in [33]. Fog cell (also called fog node) is a software component installed on a device. It takes devices to have capacity on sharing computation, communication with each other. A set of fog cells combining with others create a small Edge computing network, called a fog colony. The most powerful fog cell in a fog colony is chosen to become the orchestration node. The orchestration node has roles on managing other fog cells in its colony. Fog cell is represented in a 4-tuple, ((,), (,), (,), (,)), consisting of the following:(i)(,): Computing capacity of fog cell , measured on mega-instruction-per-second (MIPS),(ii)(,): RAM capacity of fog cell , measured on megabyte (MB),(iii)(,): Storage capacity of fog cell , measured on megabyte (MB),(iv)(,): Type capacity of fog cell . This value indicates that fog cell can execute a service which has the same type value.
The orchestration node monitors the changes of fog cells in its fog colony in order to create new relationships or remove unused relationships. A relationship between two fog cells and is a 2-tuple, ((, ), (, )), consisting of the following:(i)(,): physical distance between fog node and , measured on meter (m),(ii): average velocity between fog node and , measured on megabyte-meter-per-millisecond (MBm/ms).
4. Dynamic Resource Provisioning on Fog Landscape
4.1. Notations and Variables
Given is a fog cell, is ’s fog colony. Capacity of fog colony is equal to its orchestration node. (, ), (, ), (, ), (, ) is Computation, RAM, Storage, and Type capacity of fog node , respectively, described in Table 1.
Given application with owned set of services , service is a service of application . Service is described with a tuple ((, ), (, ), (, ), and (, )), consisting of set of Computation, RAM, Storage, and Type demand of service .
Because each service is an undividable processing unit, service will be deployed on a single device, following a 4-tuple execution plan (, , , ). An execution plan describes a service which is deployed on device at time (millisecond) using computing values (mega-instruction-per-second).
4.2. Objective Function
Given an application , with is a set of services. The requester starts from device , and the requester expects returned results to be sent to device given is a device on which service will be deployed. Our objective function is a combination of three components, (, )-the response time, ()-the network usage, and ()-server usage of application . The objective function of our proposed strategy on choosing execution plan is described as
4.2.1. Response Time
Given (, ) is the response time of service , the response time of a service is the overall time using for data processing, e.g., waiting time, input transferring time, service placement time, service execution time, and returned result transferring. Let (, ) be the response time of application . In the full-parallel case, all services of application are executed on device parallelly; the overall response time of application is equal to the maximum response time of each service as
If all services of application are placed and are executed on device parallelly, then the overall response time (, ) of application will be greater than or equal to the maximum services’ response time. If all services of application are placed and are executed on device in sequence, then the overall response time (, ) of application will be less than or equal to the total of services’ response time. Therefore, the limitation of the overall response time (, ) of application is regulated in The first subobjective function is in response time factor and is the overall response time (, ) of application .
4.2.2. Network Congestion
The communication time which is used for sending and receiving data among devices plays an important role in the overall application response time. Therefore, other proposed methods try to deploying services closer to devices, which send input/receive results, for minimizing the overall response time of an application. Data is spreading around devices which make requests for service execution. The availability of devices, which are within the effected locations, becomes decreased significantly. Moreover, the communication time within the effected locations also decreases because of the wasted bandwidth. Thus, the other considered constraint is minimizing the amount of data which is sent and received on the network environment.
Let (, ) be the network usage of service when will deploy on device given is a service in the set of ’s previous services. (, , , ) is the time for transferring service output from device to device . We compute the network usage (, ) of service deployed on device based on the total of the product of ’s output data size (denoted ()) and the time for transferring ’s output from device to device with each in ’s previous services, described as
The overall network usage of application is computed by sum of network usage of each owned services. When making decision on choice of an execution plan, we try to reduce network usage of an application as Eq. (5)- the second subobjective function in network usage factor.
4.2.3. Server Usage
Let () server usage of application be the ratio of the number of centralized executed instruction over the number of application instruction. The server usage value is computed based on the amount of cloud layer’s server usage for execution application. It means the number of instructions which are deployed and executed on servers. It also means the cost which a user has to charge when using utilities of an application. Therefore, our proposed method is minimizing the server usage parameter in order to reduce overall cost of an application. The server usage criteria are calculated as the ratio of the number of centralized executed instruction over the number of application instruction. It means how much you have to pay when an application executes. Given is a set of services which are deployed on cloud servers, server usage of application is computing as
When making decision on choice of an execution plan, we try to reduce server usage of an application as Eq. (5)- the last subobjective function in network usage factor.
Given is the device on which service will be placed and executed. Fog node is chosen to become if fog node is satisfied on the following constraints.
4.3. Constraints
4.3.1. Basic Constraints
Firstly, given (, ) is the RAM demand of service , it shows the necessary minimum amount of memory for service deployment. Given device is the device which is chosen for deploying service , has to satisfy the RAM constraint as
Additionally, (, ) is the storage demand of service , measured on megabyte. It shows the necessary minimum amount of storage for service ’s input, output, and instructor(s). Hence, if device is the device which is chosen for deploying service , then has to satisfy the Storage constraint as
The type value of service is , which defines that service is only deployed on devices with the same type value . For example, it is suited to deploy a service on the device which sends this execution request or on nearing devices if the mission of this service is only raw data preprocessing. On the other side, a service which requires the complex processing should be deployed on cloud layer’s servers. The constraint about service type is regulated in
4.3.2. Response Time
The response time (, , ) is the estimated response time of deploying service in fog node . The response time of a service is the overall time using for data processing, e.g., waiting time, input transferring time, service placement time, service execution time, and returned result transferring. Given service in a service in (), the set of previous services of , we denote the time, when service ’s output is transferred from devices to fog node as (, , , ). (, , ) is the time for executing on fog node . If service has more than two services in the previous services list, the period which is required for transferring input data from previous services’ deployed devices to device is the maximized value of each previous service. The response time (, , ) of deploying service on fog node is estimated as
For example, given a set of three services , , with two relationships (,), (,), shows us that we try to calculate for making decision on deploying service . We estimate the transfer time from device and to consider fog node is (, , , ) = 3.5s and (, , , ) = 3.3s, respectively. If we choose device for deploying service , then the response time of service is equal to 5.5s. If there are more than two suitable fog nodes ( and ), we choose the fog node which has the less estimated response time as Eq. (11) for deploying this service.
The transfer time (, , , ) is the period when service is transferred from fog node to fog node as described in (12). For example, given is the only service in set (). , are devices on which services , are deployed, respectively. Fog device stores returned result (12 megabyte data) of service after it is executed. The distance between device and is 10 meters, and its average velocity is 30 megabyte-meter-per-second. Consequently, the trans time, when service transfers its returned result from device to , is 12 x 10 / 30 = 4 seconds.
As we have introduced in Section 3.2, the orchestration node on each fog colony plays an important role to manage other fog nodes in it owning fog colony. Therefore, the distance of two fog nodes , is calculated based on a path through their owned orchestration nodes , in Figure 3. The distance value and the average velocity value of two fog nodes and arbitrarily are calculated as (13) and (14). Because the distance between two fog colonies is a positive number, we apply Dijkstra’s algorithm [34] to find the shorted path between every two fog colonies.
The execution time (, , ) is period when service will be executed on fog node , as defined in (15). For example, the execution time when service (having computation demand: 300 mega-instruction) is deployed on fog node (using computation capacity: 30 mega-instruction-per-second) takes 10 seconds. When estimating execution time of a service, we have one special case. Because computation capacity of cloud servers is unlimited, we assume that the execution time value of a service when executing on cloud servers is a tiny value, namely, about 1 millisecond.
Making decision on which device will execute a service is different among provisioning resource solutions, because of various criteria. Our proposal focuses on minimizing the total response time of the whole application. There are so many candidate devices which have enough capacity on deployment of service . We try to deploy service on device which has the minimal service response time. This is regulated in (16).
For example, in Figure 4, given a set of three services , , with two relationships (,), (,), at current time = 0, we make some calculations in order to estimate the response time of service . We find that there are two candidates option 1, option 2. Although the transfer time to device : ((, , , ), (, , , )) in option 1 is less than in option 2, we choose option 2 for deployment service into device . We know that there is a trade-off between transfer time and execution time. In option 1, the transfer time to device lasts less than in option 2, but the computation capacity on option 2 is stronger than option 2. As we see in Figure 4, the overall response time of service in option 1 (=5.5s) lasts greater time than option 2 (=4.8s). Therefore, we make decision on deployment service following option 2 because of its minimal response time value.
4.4. Service Deployment Policy
4.4.1. Cloudy Service Deployment Strategy
The cloud service policy is a service deployment policy in which service deployment follows the traditional cloud paradigm. Every service has to send preprocessing data to the cloud centralized server(s) for execution through the internet. Thus, cloud server processes request and then transfer postprocessing results from the executing cloud server to the target devices. In this case, we assume that devices (exception of cloud servers) do not have enough capacity on computation, storage, and RAM to execute a service. The cloud service policy is a base-line for evaluating our proposed deployment method in terms of the response time, network usage, and server usage.
4.4.2. Foggy Service Deployment Strategy
Service deployment is a process of matching the list of services to list of executed fog nodes based on many criteria. We use recursive approach to simplify this problem solving. Because it is simple to deploy a service on list of executing fog nodes, we find out that it is easier to match the list of services than matching list of services. Therefore, our idea is trying to deploy a service on a fitted device firstly; then, we resolve this problem with smaller scope.
Our method is described in Algorithm 1. When deploying a service on a device, we consider about types of criteria, including hard type and soft one. Hard criteria are constraints on RAM, Storage, and Type demand of a service which is described in (7), (8), and (9). They are conditions which have to be satisfied certainly. In line 5 of Algorithm 1, we use method CanDeploy(, , , ) for finding the list of current devices which have strong enough capacity for listing of available services at time . Available-Services, Available-Nodes in lines 6, 7 are lists of items with contextual data when at time , deployed services, and executing devices of Execution Plans . Line 8 estimates deployment time for finding the best deployment solution of a service, based on the objective function in (1). Then, the system has to update fog nodes‘ states and services‘ states; for example, if service - has 3 MB on RAM- placed into fog node , the current RAM capacity of fog node will decrease 3 MB. If there does NOT exist any available services at time , it will try to estimate in order to deploy the service at next period Next(). Next() is calculated by Algorithm 2.
| 1: procedure DEPLOY(, , , ) return | |
| 2: if is deployed completely then | |
| 3: return | |
| 4: else | |
| 5: if Can-Deploy(, , , ) == true then | |
| 6: for in Available-Services do | |
| 7: for in Available-Nodes(, ) do | |
| 8: Finding the best candidate(, ) | |
| 9: (, , ) | |
| 10: if Has-Deployment == true then | |
| 11: return Deploy(, , , ) | |
| 12: else | |
| 13: return Deploy(, , , Next()) | |
| 14: else | |
| 15: return Deploy(, , , Next()) |
| 1: procedure NEXT(, ) Return | |
| 2: = | |
| 3: for in do | |
| 4: if At-Executing() t then | |
| 5: if At-Executing() then | |
| 6: = At-Executing() | |
| 7: else | |
| 8: if At-Executed() t then | |
| 9: if At-Executed() then | |
| 10: = At-Executed() | |
| 11: return result |
We explain in more detail line 8 in Algorithm 1. If we choose the best candidate service deployment by basing only on policy minimizing the response time of an application, the following services of a cloudy deployed service will be deployed almost in cloud servers. Therefore, we add the network usage and the server usage criteria to make service deployment more effective and flexible. The network usage criteria are calculated on the amount of data transferred on networks in specified period.
We find out it is necessary to update the Available-Services and the Available-Nodes at two moments. They are the time when a service is being executed on a device, and the time when a service has just executed on a device. Therefore, next time of time is the moment which not only is greater than , but also has minimal difference with . Algorithm 2 describes procedure Next in detail.
Given , is the number of fog nodes, and the number of services, we use - notation to describe the performance or complexity of our algorithm. Because our system gets the current states of fog nodes, and services; for each service executing, our system costs times for comparing with all current fog nodes, and one time for assignment the most suited fog node to the executing one. In the best case (all services have the capacity for executing in parallel); the complexity of our algorithm is (mn). In the worst case (all services have to be executed in sequence), the complexity of our algorithm is (m(+)/2n). In average case (all services are regulated to executed follows tree structure with k-child nodes), the complexity of our algorithm is ((m)k(mn)).
5. Experimental Results
5.1. Application
We consider on an application type which defines service execution priority already, because this type covers all service combinations of any application. In service strings, a service uses previous services’ returned results as input data. In other words, a service sends processed data to its next services as input data. An application executed with different execution plans will return various results significantly. Different orderings of the same service combination have different meaning. There is a strict rule which requires some particular services having to be executed on cloud servers only. In practice, some services can be executed on fog devices and cloud servers, e.g., computing simple operations and raw data preprocessing. Other services can be executed only in cloud servers because this service type requires strong resources on computing, storage, e.g., data collecting from various sources, mining historical stored data. Therefore, we add the type attribute for services, devices and a strict rule defining that a service is executed on a device if they have the same type attribute value.
We introduce an application which finds the nearest direction between two locations with awareness of real-time traffic information. The nearest direction between two locations is the way which we drive from the source point to the target point with the less time. The closest in terms of physical distance direction between two locations is NOT the nearest direction between them, because of traffic problems, for example, traffic jam, accidents, and one way road. This model includes a set of public live traffic cameras in the bottom layer which play the role for capturing the traffic flows, density of vehicles on roads. The second important part is the system of mediate linked network devices which support communication among devices. Mediate linked network devices have limited capabilities on computing, storage. The final important part is cloud stage, which is a set of linked servers, known as unlimited computing, storage devices.
In this application, we divide it into two execution parts:(1)Find available directions between two locations on the cloud stage.(2)From each determined junction node, we analyze local traffic flow, density of vehicles on roads based on systems of public live traffic cameras in order to make decision on driving, for example, go straight, turn left, and turn right.
For example, Figure 5 shows a sample of finding route between two points in map. If route AD is shorter (in terms of physical distance) than route ABCD, but route AD has more crowded density of vehicles than ABCDB right now, the velocity of a vehicle on route AD may be NOT as fast as on route ABCD. Consequently, the driver on route AD takes a longer time than that on route ABCD. This is the reason why our application has to recheck the current traffic information in order to decide which way to drive dynamically. If we drive from A to D directly, it will take us 2 hours. If we drive from A to D through B and C, it will take us x hours. This is the total time we have to cost 26/15 hour. It is total of three components, 1/3 hour on route AB, 1 hour on route BC, and 2/5 hour on route CD.
5.2. Experimental Setup
We have conducted six experiments with two variables, namely, types of service strings (application types) and number of services. A list of application types includes sequence, parallel, and heterogeneous types, as we describe in Section 3.1. For each application type, we have conducted experiments for two cases: an application with 20 services, and 50 services, described in Table 4. Each service requires CPU, RAM, and storage resources of which values are randomized from ranges 2..10 mega-instruction-per-second (MIPS), 50..70 megabyte (MB), and 10..20 megabyte (MB) accordingly, described in Table 2. In heterogeneous applications, if a randomized number for each pair of services (from 0 to 100) is less than or equal to 70, we assume that there exists a relationship on execution order of them. Each service has a type attribute which is a randomized number from 1 to 5. This value indicates which devices are able to execute the considering service.
Figure 6 describes the structure of fog computing system which is the same in all six experiments. This is a tree architecture whose each node presents for a fog colony. Root of tree is a special fog colony; it includes unlimited-capacity cloud servers. Each node in tree has two child nodes. The height of tree equals four. Each fog colony includes one orchestration control node and nine other fog cells. The values of capacity on fog cells’ CPU, RAM, and storage resources are randomized from ranges 2..10 mega-instruction (MI), 80..160 MB, and 20..50 MB accordingly. The respective resources of a fog orchestration control node also are randomized from ranges 5..40 MI, 200..300 MB, and 40..100 MB. Each fog cell has a type attribute which is a randomized number from 1 to 5 as described above.
The communication link delays between two fog nodes in a fog colony and between two fog colonies have configuration with parameters described in Table 3. In reality, the communication link delays depend on the physical distance between resources, type of connection, e.g., wireless and fiber.
For each of six configurations, we deploy services following cloudy and foggy strategies which are described in Section 4.4. Firstly, we put all services into cloud, called cloudy scenarios. Then, we put services into fog landscape partially based on their deployment constraints called foggy scenarios. The differences of six configurations are the number of fog nodes, the number of services. We assume that capacity of fog nodes and demand of services do not change so much among six configurations. We find that the more the number of fog nodes, the more powerful the fog landscape’s computation capacity. Therefore, services are placed and are executed on fog landscape usefully parallelly. On the other hand, the number of services is too large for fog landscape to execute completely parallelly. So, the system costs so much time to find the suited nodes for executing services. In that case, the system places and executes services in sequence. The differences of six configurations point out the advantages between foggy and cloudy service deployment strategies.
Our objective function is combined from three components (, )-the response time, ()-the network usage, and ()-server usage with three weighted values , , and . Because of the different domains of three components in our objective function, we assume that =1, = = 0 in this work. This means that the response time of a service is the only important factor on finding the most suitable solution to deploy a service on a device. Therefore, ()-the network usage and ()-server usage will become criterion used for comparing different sides among our six configurations. However, in general case we have to consider other components. For example, if your application often disturbs near devices in order to try service deployment, then the availability of near effected devices goes down. Thus, our proposed method also considers other criteria in service deployment.
5.3. Results and Discussion
The differences of six configurations are the combinations of three types of application (sequence, parallel, and heterogeneous) with two sizes of application (20, and 50 services). We set up our systems that the capacity of fog nodes and the demand of services do not change so much (details in Table 4) among six configurations. We decide to choose that six configurations because we want to prove that the effectiveness will increase significantly if the number of services increases in the similar fog landscape. Regarding the response time of configuration 2, 5, we find that in the same fog landscape if our simulated services are able to be executed in utilized parallel, our proposed service deployment algorithms work significantly effective. On the other hand, the number of services is too great for our fog landscape to execute available services in parallel. Therefore, our fog landscape has to transfer the overloaded services into cloud servers to execute. That is the reason why the benefit on response time between foggy and cloudy service deployment strategy is not significantly effective in configuration 6.
5.3.1. Response Time
Figure 7 shows us the response time of six scenarios. Because services in parallel application (configuration 2 and 5) do not need to wait for previous completed services, the system tries to deploy the number of services on fog landscape as good as possible. In a parallel application, the response time of the foggy strategy is less than that of the cloudy strategy significantly. In configuration 1 and 3, the 20-service application has the response time of foggy strategy equal to a half of the cloudy strategy approximately. In other complex scenarios, the response time of an overall application is approximately equal to communication to cloud servers. When a service is deployed in cloud servers, list of next services will be deployed in cloud servers too because of the minimum of transmission time and execution time. Therefore, the response time of the foggy strategy in configuration 4 and 6 is less than that on the cloudy strategy significantly.
In fact, the response time rate between foggy scenarios and cloudy scenarios has significant effects in parallel cases with a great number of fog cells, because every service can be deployed if constraints are satisfied. If fog landscape has a great number of powerful fog cells, then system tries to find out a fog cell fits for service deployment. It means that services try to be deployed spreading on fog landscape. The response time rate between the foggy scenarios and the cloudy scenarios decreases gradually following from Parallel Heterogeneous Sequence cases, and a decrease of the number fog cells.
5.3.2. Network Congestion
In this work, we consider the communication between fog devices as a physical connection. When a device sends a request to or receives returned results from other devices so much, the link of this device’s connection is always on busy. This is the situation when it is difficult or slow for your devices to connect to other devices. We have conducted an experiment of network congestion metric for comparing with six above scenarios. The value of network congestion attribute is computed by the weight of transfer data multiple with transfer time. Figure 8 shows us clearly that cloudy scenarios have a great amount of data transferring over devices’ limited connections. Therefore, sending data too much is not a balanced solution for service deployment. We should utilize resources of the local and the global sides for reducing latency cost as much as possible.
5.3.3. Server Usage
The final considered parameter is server usage. The service usage is computed based on the amount of cloud layer’s server usage for execution application. It means the cost which a user has to charge when using utilities of an application. Therefore, our proposed method is minimizing the server usage parameter in order to reduce overall cost of an application. Figure 9 shows us that six deployment plans of foggy strategy cost less than that on the cloudy strategy, because of our above assumption about service deployment policy in Section 4.4.
6. Conclusion
In this work, we propose a novel method for service deployment on fog landscape. Our strategy is to combine three considered components (application’s response time, network congestion, and server usage) into one objective function. The best service deployment, we proposed, is an execution plan which has trade-off among minimizing application’s response time, minimizing network congestion, and minimizing cloud layer’s server usage.
In this work, we consider security risks on data-in-transit among devices, data-in-process on vulnerable executing devices, and privacy of data which is divided into executed parts in other devices. The existed security issue raising one of our future research directions is data protecting. This will prove that fog computing not only is an effective solution in latency applications but also is a secured one.
In future work, we will consider device’s energy consumption because of mobile devices with limited life battery. Utilization of computing sharing among near mobile devices made the application’s response time faster, but it disturbs other users by losing devices’ life battery fast. We have conducted more experimental configuration on well-known fog computing simulation environments, e.g., iFogSim [24].
One of our future research directions is finding out , value. Firstly, we have conducted experiments with a great number of situations. Secondly, we classify those situations’ configurations into approximated classes. For each class, we can deduce or update the value of beta, delta by averaged methods when our system runs with the significant number of deployment plans. Finally, we can apply accordingly , into finding optimized deployment plans in other related configurations.
Data Availability
The simulated evaluation data used to support the findings of this study are available from the corresponding author upon request.
Conflicts of Interest
The authors declare that there are no conflicts of interest regarding the publication of this paper.
Acknowledgments
This research is funded by Ho Chi Minh City University of Technology, VNU-HCM, under grant number BK-SDH-2019-1880316.