Essentially, all models are wrong, but some are useful. Collaboration Model of Fog and Cloud

Hyman Minsky

1. 
   Introduction
   

The main advantage of fog computing is the proximity to end-users devices, thus fog’s hardware and software resources are placed “closer” to things allowing services that rely on IoT-things’ inputs to be carried with minimal delay [14, 37], hence benefiting real­time applications. However, fog nodes can quickly become congested when the number of arrived service requests exceed the fog’s capability [14, 3]. Consequently, service latency occurs [14]. In addition, the potential of fog congestion occurrence is high due to the limita­tions of fog capabilities in comparison to cloud [1, 26]. Therefore, fog resource management is the most important issue/aspect of congested fog nodes [1, 15, 108], as poor resource management can lead to fog congestion which causes latency and inefficiency for services within the fog layer [6, 26]. OpenFog [38] reports that, although fog computing provides ex­tensive peer-to-peer interconnection for communication purposes with the clouds, its nodes run in silos, where no collaboration capability, for job processing, is available. Therefore, fog resource management is needed to unlock the silos and free them from the historical stovepipes working pattern. In fact, poor resource management can cause latency and in­efficiency for services within the fog [6, 26]. Therefore, in this chapter will propose a fog nodes that are able to outsource their hardware resources and participate in coordination with other fogs to achieve a single task.

The contributions of this chapter are threefold; i) the {og-2-{og coordination model that achieves an optimal workload among the collaborated fog nodes. This coordination model allow fogs to outsource their resource. ii) a Fog Resource manAgeMEnt Scheme (FRAMES) that promotes load balancing to address the latency concern of service request’s received from things. We adopt the notion of fog-as-a-service [157] where each fog node hosts local computation, networking and storage capabilities. and iii) a formal mathematical model that backs the decision of load balancing among fog nodes via offloading. The offloading model considers not only the queue length of the service packets, but also variant node capabilities as well as different data packets or request types, such as, heavy-weight data packets from a CCTV and low-weight data packets from sensors. The proposed models and their algorithms outperformed the output of two benchmark algorithms; Random Walk Algorithm (RWA) and Neighbouring Fogs Algorithm (NFA).

2. 
   Fog Resource manAgeMEnt Scheme
   

Although fog nodes are placed “closer” to IoT things so, that, latency is “taken care” of, these nodes can quickly become congested when the number of requests soliciting their services exceed their capabilities [14] [3]. The fog layer in the IoT architecture consists of heterogeneous devices clustered together and forming what is called “fog domains”. Each fog device/node has it is own coverage range where the desired fog services are provided. In fact, due to node heterogeneity, service types and sizes (e.g., processing speed and storage capacity) vary from one fog node to another, thus its unclear how fog services are managed and provided. Many questions arise: “How can fog’s services be provided?” and “Who does manage and monitor fog resources consumption and provisioning?” in order to evaluate the QoS and performance of the fog devices. To fill this gap, Fog Resource manAgeMEnt Scheme (FRAMES) is proposed. This section discusses FRAMES, which involves managing fog resources status and provides network analysis and statistics for fog resource provision­ing and consumption. Figure 5.1 shows the conceptual diagram of FRAMES. The main functionality is to periodically monitoring fogs' statuses and network loads.

1. 
   Fog management scheme
   

Fog nodes/devices can be any device with storage, computing, and network capabilities. Fog can be directly installed by an individual user or network administrator who wants to benefit from desired fog services. Therefore, FRAMES is based on the fog node mesh distribution architecture [20, 4], which is similar to the distribution of WiFi access point topology [4] (i.e., installing routers in a distributed manner with respect to coverage range). Thus, network administrators install multiple interconnected networks of fog nodes in public places (e.g., cities) and private places (e.g., homes) to distribute fog services. This way of fog services distribution is achieved through collaboration between cloud providers, IoT operators, and network infrastructure providers. FRAMES can manage the distribution of fog nodes as well as the monitoring of performance and resources managements in the fog layer. FRAMES includes three main parties which take over the process of managing fog services and coherence as per Figure 5.2.

Figure 5.1: Overview of the Fog Resource manAgeMEnt Scheme

• Fog Portal: is a distributed software, which is located within each fog domain and forms an intermediate connector between the fog nodes and services’ users. This portal features a knowledge-base on a connected fog domain and cloud-based data repository to provide data about all the available fog domains and the services pro­vided by each fog node, thus share data/statistics between fog nodes. The procedure of declaring new/existing fog services via the fog portal starts when the fog owner connects the actual fog node to the IoT network. Thus, as soon as the node is up and running, it will be detected by the local network and assign a unique static IP address to the device, and at this point the node will ping the portal to register de-

Figure 5.2: Sequence diagram showing FRAMES interactions

vice details in the fog portal. During the registration process, all device information and capabilities of the device are required, such as, device CPU clock, storage size, network capacity, MAC addresses identifier alongside with the IP address assigned by the network which will be used to identify the node. At this time, or thereafter, the fog owner can visit the portal and assign/declare the desired fog services.

• Fog Finger: is an automated ping utility, which is run by FRAMES on a periodic schedule (set according network/admin needs) to check the status of registered fog nodes in each individual domain. The outcome will be reported to the main manage­ment portal upon which action is taken in case a fog node is down. The ping utility operate by sending Internet Control Message Protocol (ICMP) echo request packets which is very tiny in term of size, more precisely, it is 84 Bytes including the ICMP and IP headers [158], hence it dose not cause an overhead load in the network. More­over, the pinger is network's admin feature that uses the services of the Internet Control Message Protocol (ICMP) which encapsulate in an IP header. Thus, pinger

operates on the Network layer of the Open Systems Interconnection (OSI) model.

•