Minimizing Delay in IoT Systems Through Collaborative Fog-to-Fog

Minimizing Delay in IoT Systems Through Collaborative Fog-to-Fog (F2F) Communication Wassim Masri, Ismaeel Al Ridhawi1, Nour Mostafa1, Pardis Pourghomi1 College of Engineering and Technology American University of the Middle East (AUM) Egaila, Kuwait {Ismaeel.Al-Ridhawi; Nour.Moustafa; Pardis.Pourghomi}@aum.edu.kw 1

Abstract—The recent advances in IoT technologies have led to the introduction of a plethora of networking, storage and computing systems. Today, the cloud computing system has evolved into the so-called fog-cloud computing paradigm to include computation, storage, and data exchange capabilities of edge devices. Although this rapid pace of evolution has led to the introduction of many IoT smart scenarios, many low-latency high-rate service scenarios are still considered impractical to be implemented. In this paper, we introduce a fog-to-fog (F2F) communication algorithm that allows fogs to communicate with each other to process job requests. In this type of communication paradigm, fogs are not limited to either execute a task or forward it to the cloud but also have the capability to collaborate with other neighboring fogs. This will minimize the overall end-to-end (e2e) latency. Case studies are considered in this paper to demonstrate that the adopted strategy may be applied to the FogCloud system to reduce the overall e2e delay. Keywords—Cloud, Fog, IoT.

I. INTRODUCTION Traditionally, IoT devices such as vehicles, smartphones, traffic lights, power plants, medical facilities, home automation devices, and other IoT sensors, used to communicate directly with the remote cloud for task submission. This incurs high delays and network bandwidth overload. A considerable amount of traffic generated by the enormous number of IoT sensors should actually be processed and filtered before being sent to the cloud, otherwise, the whole IoT scheme would be highly challenging to implement. The fog computing paradigm [1] was introduced to solve this issue, specifically for real-time applications with low-delay constraints, such as health-care solutions, which demand prompt response and processing. A fog layer within the Fog-to-Cloud (F2C) architecture was introduced to solve communication latency issues. The fog layer is an intermediate layer between the IoT devices and the cloud (Figure 1), which extends the traditional cloud computing paradigm towards the underlying networks. By bringing the network and cloud resources closer to the network edge, substantial amount of jobs will be processed near the IoT devices instead of sending data all the way to the cloud. This will lead to reduced communication delays and thus enabling many latency-sensitive services that would have been impractical to be implemented otherwise.

978-1-5090-4749-9/17/$31.00 ©2017 IEEE

1005

The fog layer consists of several independent fogs, where each fog contains a micro-datacenter, and different levels of storage and processing powers. The fog layer will enable storage, pre-processing, data fusion, and other crucial services that would offload the cloud and offer better QoS for IoT users. In the F2C scenario, whenever a node in the IoT layer submits a job to be processed or stored, the node will first contact the fog it is connected with, instead of submitting the job directly to the cloud. The fog then decides whether to undertake the job itself or forward it to the cloud for processing. Although the fog layer is introduced as a practical solution to the IoT system, it should be noted that since the fog has lower storage and processing capabilities than the cloud, it might at times refuse to undertake new jobs if it had reached its maximum capacity, hence the concept of fog availability which was not accounted for before within fog-cloud systems is considered in this paper. Accordingly, we propose in this paper a novel approach which we call Fog-to-Fog communication (F2F), where fogs are not limited anymore to either execute a task or forward it to the cloud, but also to communicate with other fogs to process the job request. This will minimize the overall end-toend latency and help the IoT system reach its maximum potential. The remainder of the paper is organized as follows. In section II we discuss background information and related approaches in the literature. Section III introduces the F2F communication scheme given different scenarios. Section IV describes the proposed F2F communication algorithm. Case studies are reported in Section V. Finally, section VI concludes the paper with future work directions. II. RELATED WORK With the increase in the number of sensors, actuators, and mobile nodes, IoT has emerged as a promising supporting solution for seamless and ubiquitous computing. IoT provides potential for developing new intelligent solutions in nearly every field such as smart home [2], smart healthcare [3], and smart environmental monitoring [4]. Many challenges arise from IoT systems related to data- storage, processing and networking issues [5]. One of the main issues of IoT is the amount of data generated from sensors and transmitted to the cloud. To overcome such storage and transmission challenges, the authors in [6] developed a distributed cloud storage

ICUFN 2017

into different fog layers. Although the presented work provides a unique solution to coordinate the management of F2C computing systems, however, the presented strategy did not show or explain how the service is divided into individual functions, and neither talk about the criteria used by the management system in choosing the optimal fog.

Fig.1. Fog-Cloud architecture.

replication technique for data generated from IoT sensors. The solution assumes the existence of multiple distributed cloud data centers, called mini-Clouds, among which data can be replicated to. The problem is modeled based on the bandwidth of the network and the available number and size of data storage capacity at each mini-cloud. The solution aims at reducing the time needed to replicate the data. A greedy heuristic optimization method is adopted for the delay minimization problem. Another solution presented in [7] considers the issue of optimizing data transmissions from IoT sensors to the cloud in order to support more IoT sensors to provide a higher diversity of sensed parameters. A reinforced learning technique is used to predict the data that sensors will transmit in the future, such that data that can be predicted will not have to be transmitted, thus reducing the amount of data transmissions. Although many novel research efforts were considered to solve the problems of IoT data storage, processing, transmission and control, through cloud-based systems, however, for critical systems such as health-monitoring, emergency response and other latency-sensitive applications, the delay caused by transferring data to the cloud and back is intolerable. To address this issue, fog computing was introduced to allow for the integration of edge devices and cloud resources to help overcome latency issues. Fog computing is a distributed paradigm that provides cloud-like services to the network edge [8]. Studies on fog computing are still premature, leading to many emergent architectures for computing, storage, control, and networking that distributes these services closer to end-users. In [9] a Fog-to-Cloud (F2C) architecture was introduced which consists of a layered management structure that integrates different heterogeneous cloud/fog layers into a hierarchal architecture. Different cloud implementations and concepts are dynamically setup and released on the fog layer. The work focuses on a control strategy used to coordinate the different resources of both the fog and cloud to provide the overall F2C layered architecture. A management system responsible for discovering a set of available fogs is developed to select the best fog available to meet certain service requirements. The proposed solution assumes that the service can be divided into individual functions which in turn are split

1006

Souza et al. [10] proposed a QoS-aware service distribution strategy in F2C scenarios. The work aims at achieving low delay on service allocation by using service atomization in which services are decomposed into distinct sub-services called atomic services tailored to enable parallel execution. These atomic services are executed on constrained edge devices. Tasks with higher requirements are allocated on more robust resources and executed in parallel with the atomic services. A control plane within the F2C architecture exists that is responsible for the distribution of the atomic services among the available edge nodes. The service allocation process aims at reducing the service allocation delay, providing load balance and energy-usage balance among the distinct fogs. The authors model the service allocation problem as a multi-dimensional knapsack problem (MKP). Although the authors presented a F2C service allocation solution, their work neglected key node resource capabilities such as processing power and storage capacity that must be considered when allocating services. On a similar note, the authors in [11] presented an efficient and trustworthy resource sharing platform for collaborative cloud computing. Although the F2C architecture is not considered in their work, cooperation between clouds belonging to different entities are used in a cooperative manner to provide services. Both cloud resources and cloud service reputation are considered for the resource selection process. The system allows users to perform resource selection with joint consideration of diverse QoS requirements such as reputation, efficiency, and price with different priorities. A trading model is implemented which enables cloud nodes to adaptively adjust its resource price to maximize its profit and maintain high reputation while avoiding being overloaded. This allows for full and fair utilization of resources in the cloud system. Although there exists extensive research in the area of cloud resource sharing, work in fog resource sharing and cooperation is still premature. We believe that our work is the first to consider a Fog-to-Fog (F2F) architecture that allows fogs to communicate with each other to allow IoT reach its maximum potential in terms of service delay reduction. III. FOG-TO-FOG COMMUNICATION SCHEME A. Definitions Each IoT device is able to submit a job 𝐽𝐽𝑖𝑖 for processing, storage, or both, to the Fog-Cloud system. Each job 𝐽𝐽𝑖𝑖 will have certain requirements denoted by an ordered 2-tuple: 𝐽𝐽𝐽𝐽𝑖𝑖 = 〈𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆, 𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀〉

(1)

where 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 denotes the size of the job to be transmitted, and 𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀 denotes the upper bound on the roundtrip transmission delay allowed for the job.

The time it takes a job 𝐽𝐽𝑖𝑖 to be transmitted to 𝐹𝐹𝐹𝐹𝐹𝐹𝑗𝑗 is denoted: 𝐷𝐷𝐷𝐷𝐷𝐷𝑖𝑖,𝑗𝑗 . The time it takes a job 𝐽𝐽𝑖𝑖 to be forwarded from 𝐹𝐹𝐹𝐹𝐹𝐹𝑗𝑗 to 𝐹𝐹𝐹𝐹𝐹𝐹𝑘𝑘 (F2F communication) is denoted by 𝐹𝐹2𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝑖𝑖,𝑗𝑗,𝑘𝑘 . The roundtrip delay that a job 𝐽𝐽𝑖𝑖 takes to be submitted to 𝐹𝐹𝐹𝐹𝐹𝐹𝑗𝑗 , and sent back to the node that submitted the job, assuming no F2F communication is happening and where the fog itself is handling the job, is denoted by 𝑅𝑅𝑅𝑅𝑖𝑖,𝑗𝑗 and is calculated as follows: 𝑅𝑅𝑅𝑅𝑖𝑖,𝑗𝑗 = 2 ∗ 𝐷𝐷𝐷𝐷𝐷𝐷𝑖𝑖,𝑗𝑗

(2)

When F2F communication is considered, a 𝐹𝐹𝐹𝐹𝐹𝐹𝑗𝑗 might delegate another 𝐹𝐹𝐹𝐹𝐹𝐹𝑘𝑘 to service the job 𝐽𝐽𝑖𝑖 . Before transmitting 𝐽𝐽𝑖𝑖 to 𝐹𝐹𝐹𝐹𝐹𝐹𝑘𝑘 , 𝐹𝐹𝐹𝐹𝐹𝐹𝑗𝑗 needs to make sure that 𝐹𝐹𝐹𝐹𝐹𝐹𝑘𝑘 will not be accepting any jobs that would compromise its ability to service 𝐽𝐽𝑖𝑖 . Thus, a 3-way handshake would be necessary between both fogs to ensure that 𝐹𝐹𝐹𝐹𝐹𝐹𝑘𝑘 will be waiting for 𝐹𝐹𝐹𝐹𝐹𝐹𝑗𝑗 to submit 𝐽𝐽𝑖𝑖 . We denote 𝐻𝐻𝐻𝐻𝑗𝑗,𝑘𝑘 as the time it takes for a handshake to be completed between 𝐹𝐹𝐹𝐹𝐹𝐹𝑗𝑗 and 𝐹𝐹𝐹𝐹𝐹𝐹𝑘𝑘 : 𝐻𝐻𝐻𝐻𝑗𝑗,𝑘𝑘 = 𝑇𝑇 + 𝑇𝑇_𝐴𝐴𝐴𝐴𝐴𝐴 + 𝐴𝐴𝐴𝐴𝐴𝐴

(3)

where 𝑇𝑇 denotes the time the 2-tuple 𝐽𝐽𝐽𝐽𝑖𝑖 needs to be transmitted from 𝐹𝐹𝐹𝐹𝐹𝐹𝑗𝑗 to 𝐹𝐹𝐹𝐹𝐹𝐹𝑘𝑘 . 𝑇𝑇_𝐴𝐴𝐴𝐴𝐴𝐴 denotes the time it takes for the acknowledgment of the tuple (and hence the acceptance of 𝐹𝐹𝐹𝐹𝐹𝐹𝑘𝑘 to undertake the job) to be transmitted from 𝐹𝐹𝐹𝐹𝐹𝐹𝑘𝑘 to 𝐹𝐹𝐹𝐹𝐹𝐹𝑗𝑗 . 𝐴𝐴𝐴𝐴𝐴𝐴 denotes the time it takes the confirmation to travel from 𝐹𝐹𝐹𝐹𝐹𝐹𝑗𝑗 to 𝐹𝐹𝐹𝐹𝐹𝐹𝑘𝑘 . All three components could be easily calculated knowing the size of 𝐽𝐽𝐽𝐽𝑖𝑖 , the size of the acknowledgment packets, and the bandwidth of the link. The roundtrip delay that a job 𝐽𝐽𝑖𝑖 takes to be submitted to 𝐹𝐹𝐹𝐹𝐹𝐹𝑗𝑗 , and sent back to the node that submitted the job, assuming 𝐹𝐹𝐹𝐹𝐹𝐹𝑗𝑗 is submitting the job to another fog 𝐹𝐹𝐹𝐹𝐹𝐹𝑘𝑘 , is denoted by 𝐹𝐹𝐹𝐹𝐹𝐹𝑖𝑖,𝑗𝑗 and is calculated as follows: 𝐹𝐹𝐹𝐹𝐹𝐹𝑖𝑖,𝑗𝑗 = 2 ∗ 𝐷𝐷𝐷𝐷𝐷𝐷𝑖𝑖,𝑗𝑗 + 2 ∗ 𝐹𝐹2𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝑖𝑖,𝑗𝑗,𝑘𝑘 + 𝐻𝐻𝐻𝐻𝑗𝑗,𝑘𝑘

(4)

𝐹𝐹𝐹𝐹𝑖𝑖 = 〈𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴, 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆, {𝐽𝐽}〉

(5)

Let {𝐹𝐹} be the set of all available fogs in the system, and let 𝐶𝐶 denote the cloud. For each 𝐹𝐹𝐹𝐹𝐹𝐹𝑖𝑖 ∈ {𝐹𝐹} we assign an ordered 3-tuple fog capacity 𝐹𝐹𝐹𝐹𝑖𝑖 such that:

where 𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴 is a Boolean that denotes whether or not 𝐹𝐹𝐹𝐹𝐹𝐹𝑖𝑖 is capable of handling new jobs, 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑔𝑔𝑔𝑔 denotes the available storage, and {𝐽𝐽} denotes the set of all active jobs handled by 𝐹𝐹𝐹𝐹𝐹𝐹𝑖𝑖 . The set {𝐽𝐽} is dynamic, hence any new jobs undertaken by the fog should be added to the set, and any finished jobs should be immediately removed. Moreover, we assume that each fog knows the delay incurred to reach any other fog in the system, since the bandwidth of the links connecting them are static. The cloud is assumed to be always available to handle any job of any storage and processing requirements, and hence it is not assigned a capacity n-tuple like fogs.

1007

B. Scenarios In what follows, we present several different scenarios where different aspects of F2C communication and F2F communication are presented and discussed. i) IoT device is connected to a Fog and needs to submit a job. F2F communication is not considered. In this scenario (Figure 2), let’s assume that node S needs to submit a job 𝐽𝐽1 to the cloud. Node S is connected to 𝐹𝐹𝐹𝐹𝐹𝐹2 , so S will submit the job to 𝐹𝐹𝐹𝐹𝐹𝐹2 along with its 2-tuple requirements (i.e. 𝐽𝐽𝐽𝐽1 ). Cloud

Fog 1

Fog 2

FC2:

Fog 3

S

JR1:

Fig. 2. Node S is connected to Fog 2 and has a job to submit to the cloud.

𝐹𝐹𝐹𝐹𝐹𝐹2 will check the maximum delay allowed by 𝐽𝐽1 and will perform the following: a) If 𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝐽𝐽𝐽𝐽1 is above a certain threshold set in the system, then the job is deemed to be delay insensitive, and 𝐹𝐹𝐹𝐹𝐹𝐹2 will forward 𝐽𝐽1 to the cloud. This is a traditional F2C communication example.

b) If 𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝐽𝐽𝐽𝐽1 is below the threshold, then the fog layer will attempt to service 𝐽𝐽1 instead of the cloud. 𝐹𝐹𝐹𝐹𝐹𝐹2 will handle 𝐽𝐽1 if the following conditions are satisfied: 𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐹𝐹𝐹𝐹2 = 𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇

∀ 𝐽𝐽𝑖𝑖 ∈ {𝐽𝐽}𝐹𝐹𝐹𝐹2 , ∑ 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝐽𝐽𝐽𝐽𝑖𝑖 ≤ 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝐹𝐹𝐹𝐹2 𝑅𝑅𝑅𝑅1,2 ≤ 𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑙𝑙𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐽𝐽𝐽𝐽1

(6)

(7) (8)

If one or more conditions of the above couldn’t be satisfied (e.g. the fog is not available), then 𝐹𝐹𝐹𝐹𝐹𝐹2 will forward 𝐽𝐽1 to the cloud. We believe that this case will often be encountered in the IoT environment, where the fog might be handling many requests at the same time, and hence, will not be available sometimes to handle any more jobs. The job will be submitted to the cloud, and its delay-related constraints might then be compromised. This could be tackled using our F2F scheme presented below. ii) IoT device is connected to a Fog and needs to submit a job. F2F communication is considered. In this scenario (Figure 3), let’s assume that node S needs to submit a job 𝐽𝐽1 to the cloud. Node 𝑆𝑆 is connected to 𝐹𝐹𝐹𝐹𝐹𝐹2 , so 𝑆𝑆 will submit the job to 𝐹𝐹𝐹𝐹𝐹𝐹2 along with its 2-tuple requirements (i.e. 𝐽𝐽𝐽𝐽1 ).

Algorithm 1: Fog Selection

Cloud

Fog 1

F2F communication

Fog 2

F2F communication

FC2:

Fog 3

S

JR1:

Fig. 3. Node S is connected to Fog 2 and has a job to submit to the cloud. F2F is considered in this case to avoid the job from being transmitted to the cloud and rather have one of the fogs complete the job.

In this scheme, 𝐹𝐹𝐹𝐹𝐹𝐹2 is connected to both 𝐹𝐹𝐹𝐹𝐹𝐹1 and 𝐹𝐹𝐹𝐹𝐹𝐹3 and hence F2F communication is considered. 𝐹𝐹𝐹𝐹𝐹𝐹2 will check the maximum delay allowed by 𝐽𝐽1 and will perform the following: a) If 𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝐽𝐽𝐽𝐽1 is above a certain threshold set in the system, then the job is deemed to be delay insensitive, and 𝐹𝐹𝐹𝐹𝐹𝐹2 will forward 𝐽𝐽1 to the cloud. This is a traditional F2C communication example.

b) If 𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝐽𝐽𝐽𝐽1 is below the threshold, then the fog layer will attempt to service 𝐽𝐽1 instead of the cloud. However, 𝐽𝐽1 may not be necessarily serviced by 𝐹𝐹𝐹𝐹𝐹𝐹1 , since another fog in the fog layer might be able to handle the job more efficiently (i.e. with a lower delay). 𝐹𝐹𝐹𝐹𝐹𝐹2 should communicate with its neighbors and will delegate another fog for the job if there exists a better candidate. We call this type of communication F2F. 𝐹𝐹𝐹𝐹𝐹𝐹2 will submit 𝐽𝐽1 to 𝐹𝐹𝐹𝐹𝐹𝐹𝑗𝑗 when the following conditions are satisfied: 𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐹𝐹𝐹𝐹𝑗𝑗 = 𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇

∀ 𝐽𝐽𝑖𝑖 ∈ {𝐽𝐽}𝐹𝐹𝐹𝐹𝑗𝑗 , ∑ 𝑆𝑆𝑆𝑆𝑆𝑆𝑒𝑒𝐽𝐽𝐽𝐽𝑖𝑖 ≤ 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝐹𝐹𝐹𝐹𝑗𝑗 𝐹𝐹𝐹𝐹𝐹𝐹1,𝑗𝑗 ≤ 𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝐽𝐽𝐽𝐽1

(9)

(10) (11)

∄ 𝐹𝐹𝐹𝐹𝐹𝐹𝑘𝑘 ∈ {𝐹𝐹}: 𝐹𝐹𝐹𝐹𝐹𝐹1,𝑘𝑘 < 𝐹𝐹𝐹𝐹𝐹𝐹1,𝑗𝑗 ∧ 𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐹𝐹𝐹𝐹𝑘𝑘 = 𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 (12)

If one or more conditions of the above couldn’t be satisfied (e.g. none of the fogs are available), then 𝐹𝐹𝐹𝐹𝐹𝐹2 will forward 𝐽𝐽1 to the cloud. IV. PROPOSED ALGORITHM

The resource selection algorithm which will select the most appropriate fog to handle a certain job submitted to the fog layer while minimizing the delay is presented in Algorithm 1. We assume that a node 𝑆𝑆 is submitting a job 𝐽𝐽1 to 𝐹𝐹𝐹𝐹𝐹𝐹2 with 𝐽𝐽𝐽𝐽1 = 〈𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆, 𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀〉 , and 𝐹𝐹𝐹𝐹2 = 〈𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴, 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆, {𝐽𝐽}〉. V. CASE STUDIES

In what follows, we present several case studies that illustrate the advantages of our approach (F2F) in contrast to the traditional F2C approach. Consider a node 𝑆𝑆 that needs to submit a job to the cloud, the following examples showcase

1008

SumSizei = 0; start S submits J1 to Fog2; //If the maximum delay allowed by J1 > THRESHOLD if (MaxDelAllowedJR1 > THRESHOLD) then Fog2 submits J1 to the cloud; else foreach available Fogi neighboring Fog2 do foreach Jobj in {J}FCi //including J1 //Sum the size of all jobs being handled //by Fogi SumSizei += SizeJRj; end foreach //if Fogi didn’t reach its storage capacity //yet and the delay to submit J1 and send it //back, is less than the delay permitted by //J1, then Fogi is added to the list of //candidates fogs to service J1 if (SumSizei 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝐹𝐹𝐹𝐹2 (18)

Fig. 6. 𝐽𝐽1 is a pressure change signal with low-delay and low-storage constraints, and having capability of F2F communication.

Since 𝐹𝐹𝐹𝐹𝐹𝐹1 and 𝐹𝐹𝐹𝐹𝐹𝐹2 are not available, 𝐹𝐹𝐹𝐹𝐹𝐹2 will try to submit the job to 𝐹𝐹𝐹𝐹𝐹𝐹3 if possible. We assume that 𝐹𝐹𝐹𝐹𝐹𝐹3 will not reach its storage capacity if it accepted to process 𝐽𝐽1 , hence the condition outlined in (10) is satisfied.

Moreover, we assume that 𝐹𝐹2𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹1,2,3 = 0.5𝑠𝑠 , 𝐷𝐷𝐷𝐷𝐷𝐷1,2 = 0.2𝑠𝑠, and 𝐻𝐻𝐻𝐻2,3 = 0.3, then: 𝐹𝐹𝐹𝐹𝐹𝐹1,3 = 2 ∗ 𝐷𝐷𝐷𝐷𝐷𝐷1,2 + 2 ∗ 𝐹𝐹2𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹1,2,3 + 𝐻𝐻𝐻𝐻2,3 = 2 ∗ 0.2 + 2 ∗ 0.5 + 0.3 = 1.7𝑠𝑠 ≤ 2𝑠𝑠 (𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝐽𝐽𝐽𝐽1 )

The condition outlined in (11) is hence satisfied, and 𝐹𝐹𝐹𝐹𝐹𝐹2 submits 𝐽𝐽1 to 𝐹𝐹𝐹𝐹𝐹𝐹3 for processing. Using F2F communication in this scenario prevented the job from missing its deadline (as in case study 1), by consolidating all the independent fogs into one big abstract fog. D. Case study 4: Fog-cloud architecture, F2F enabled, lowdelay constraint, high-storage requirement. We assume that 𝑆𝑆 is an aircraft and 𝐽𝐽1 is flight data with medium delay and high storage constraints (Figure 7), where: 𝐽𝐽𝐽𝐽1 = 〈200𝑀𝑀𝑀𝑀, 30𝑠𝑠〉

Fig. 5. 𝐽𝐽1 is flight data with medium-delay and low-storage constraints, and no capability of F2F communication.

1009

𝐹𝐹𝐹𝐹2 = 〈𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇, 350𝑀𝑀𝑀𝑀, {𝐴𝐴, 𝐵𝐵}〉

(21)

(22)

Node 𝑆𝑆 will submit the job to 𝐹𝐹𝐹𝐹𝐹𝐹2 which will not necessarily process the job by itself. 𝐹𝐹𝐹𝐹𝐹𝐹2 will submit the job

computing scheme within the IoT environment by bringing network, processing, and storage resources closer to the devices, hence helping them meet their hard-constraints and offloading much of their data to the fog. In this paper, we introduced a novel approach in fog computing, the Fog-to-Fog (F2F) communication scheme, where a fog might delegate another, more suitable fog, to process and/or store a job. This approach enhances and upgrades the traditional Fog-to-Cloud (F2C) communication and highly increases the probability for a job to meet its delayrelated requirements. In the F2F communication scheme, all fogs in the fog layer will be consolidated into one virtual fog with higher availability and better storage and processing power. Fig. 7. 𝐽𝐽1 is flight data with medium-delay and high-storage constraints, and having capability of F2F communication.

for processing by one of the fogs when the conditions outlined in (9) and (12) are met by adapting Algorithm 1. We assume that nodes A and B have already submitted jobs to 𝐹𝐹𝐹𝐹𝐹𝐹2 , where 𝐽𝐽𝐽𝐽2 = 〈100𝑀𝑀𝑀𝑀, 20𝑠𝑠〉 , and 𝐽𝐽𝐽𝐽3 = 〈150𝑀𝑀𝑀𝑀, 25𝑠𝑠〉. In this case, the condition outlined in (10) is not met on 𝐹𝐹𝐹𝐹𝐹𝐹2 since: ∀ 𝐽𝐽𝑖𝑖 ∈ {𝐽𝐽}𝐹𝐹𝐹𝐹2 ,

∑ 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝐽𝐽𝐽𝐽𝑖𝑖 = 100 + 150 + 200 = 450𝑀𝑀𝑀𝑀 > 350𝑀𝑀𝑀𝑀 (𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝐹𝐹𝐹𝐹2 )

(23)

(24)

We assume that 𝐹𝐹𝐹𝐹𝐹𝐹1 and 𝐹𝐹𝐹𝐹𝐹𝐹3 will not reach their storage capacity if they accepted to process 𝐽𝐽1 , hence the condition outlined in (10) is satisfied for both. Moreover, we assume that 𝐹𝐹2𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹1,2,3 = 3𝑠𝑠 , 𝐻𝐻𝐻𝐻2,3 = 0.3𝑠𝑠 , 𝐷𝐷𝐷𝐷𝐷𝐷1,2 = 2𝑠𝑠 , 𝐹𝐹2𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹1,2,1 = 2𝑠𝑠 , and 𝐻𝐻𝐻𝐻2,1 = 0.2𝑠𝑠.

Then,

𝐹𝐹𝐹𝐹𝐹𝐹1,3 = 2 ∗ 𝐷𝐷𝐷𝐷𝐷𝐷1,2 + 2 ∗ 𝐹𝐹2𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹1,2,3 + 𝐻𝐻𝐻𝐻2,3 = 2 ∗ 2 + 2 ∗ 3 + 0.3 = 10.3𝑠𝑠 ≤ 30𝑠𝑠 (𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝐽𝐽𝐽𝐽1 )

On the other hand,

𝐹𝐹𝐹𝐹𝐹𝐹1,1 = 2 ∗ 𝐷𝐷𝐷𝐷𝐷𝐷1,2 + 2 ∗ 𝐹𝐹2𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹1,2,1 + 𝐻𝐻𝐻𝐻2,1 = 2 ∗ 2 + 2 ∗ 2 + 0.2 = 8.2𝑠𝑠 ≤ 30𝑠𝑠 (𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝐽𝐽𝐽𝐽1 )

Both fogs (𝐹𝐹𝐹𝐹𝐹𝐹1 and 𝐹𝐹𝐹𝐹𝐹𝐹3 ) satisfy the condition outlined in (11), hence both are possible candidates. The fog selection algorithm will choose the fog which will incur the minimal delay as outlined in (12), hence 𝐹𝐹𝐹𝐹𝐹𝐹2 will submit 𝐽𝐽1 to 𝐹𝐹𝐹𝐹𝐹𝐹1 for processing. Using F2F communication in this scenario prevented the job from missing its deadline (as in case study 2), by consolidating all the independent fogs into one big abstract fog. VI. CONCLUSION AND FUTURE WORK Cloud computing is surely an interesting solution for many enterprises and businesses, however, it became clear that the present cloud architecture will not able to handle the enormous amounts of data collected by thousands of nodes across the network when seen in the IoT context. Fog computing came to mitigate the shortcomings of the cloud

1010

The work presented here could still be improved by examining more variables that could affect the communication between fogs or between the cloud and the fog layer. Moreover, other aspects of the fogs could be investigated and utilized, such as looking at the task processing history in each fog and each node, and using this information to predict future jobs. In this work, we focused on defining the framework and formalizing the way F2F communication occurs. The next step will target validating our model through simulations and reallife implementations. REFERENCES [1]

M. Aazam and E. N. Huh, "Fog Computing: The Cloud-IoT/IoE Middleware Paradigm," in IEEE Potentials, vol. 35, no. 3, pp. 40-44, May-June 2016. [2] M. Collotta and G. Pau, "An Innovative Approach for Forecasting of Energy Requirements to Improve a Smart Home Management System Based on BLE," in IEEE Transactions on Green Communications and Networking, vol. 1, no. 1, pp. 112-120, March 2017. [3] H. Demirkan, "A Smart Healthcare Systems Framework," in IT Professional, vol. 15, no. 5, pp. 38-45, Sept.-Oct. 2013. [4] B. Andò, S. Baglio, A. Pistorio, G. M. Tina and C. Ventura, "Sentinella: Smart Monitoring of Photovoltaic Systems at Panel Level," in IEEE Transactions on Instrumentation and Measurement, vol. 64, no. 8, pp. 2188-2199, Aug. 2015. [5] J. A. Stankovic, "Research Directions for the Internet of Things," in IEEE Internet of Things Journal, vol. 1, no. 1, pp. 3-9, Feb. 2014. [6] A. Kumar, N. C. Narendra and U. Bellur, "Uploading and Replicating Internet of Things (IoT) Data on Distributed Cloud Storage," in Proc. IEEE 9th International Conference on Cloud Computing (CLOUD), San Francisco, CA, 2016, pp. 670-677. [7] G. M. Dias, B. Bellalta, and S. Oechsner, “Prediction-Based Strategies for Reducing Data Transmissions in the IoT,” Ph.D. dissertation, Pompeu Fabra University, 2016. [Online]. Available: http://gmdias.com/MartinsDias_Thesis.pdf. [8] A. V. Dastjerdi and R. Buyya, "Fog Computing: Helping the Internet of Things Realize Its Potential," in Computer, vol. 49, no. 8, pp. 112-116, Aug. 2016. [9] X. Masip-Bruin, E. Marín-Tordera, G. Tashakor, A. Jukan and G. J. Ren, "Foggy clouds and cloudy fogs: a real need for coordinated management of fog-to-cloud computing systems," in IEEE Wireless Communications, vol. 23, no. 5, pp. 120-128, October 2016. [10] V. B. Souza, X. Masip-Bruin, E. Marin-Tordera, W. Ramirez and S. Sanchez, "Towards Distributed Service Allocation in Fog-to-Cloud (F2C) Scenarios," in Proc. 2016 IEEE Global Communications Conference (GLOBECOM), Washington, DC, 2016, pp. 1-6. [11] H. Shen and G. Liu, "An Efficient and Trustworthy Resource Sharing Platform for Collaborative Cloud Computing," in IEEE Transactions on Parallel and Distributed Systems, vol. 25, no. 4, pp. 862-875, April 2014.