Application of IoT ‐ Fog based real ‐ time monitoring system for open ‐ cast mines—A survey

Fog computing (FC) archetypes is in focus recently for its potential to utilise resources optimally by the Internet of Things (IoT) network bearing ample end ‐ devices. This enhances the quality of service (QoS) to the proximity of end ‐ users as latency ‐ free processing is obtained in cloud ‐ IoT ‐ based environs. Mining industry will encounter a level ‐ up due to these technological advancements like fog ‐ IoT ‐ based systems. Monitoring mining activities such as blasting, slope monitoring, and miner tracking are time ‐ sensitive. Hence, instant response is demand of extreme mine environment so that life and property are not compromised. New opportunities emerge in mining since the FC approach addresses these demands depending on the demand of the situation/user. The parameters of integrating the state ‐ of ‐ art of fog, IoT, and cloud architectures are provided, and a Fog ‐ IoT mines monitoring (FIoTMM) system for real ‐ time monitoring of open ‐ cast mines is proposed. This work also envisions the applications and future trends of FC concerning IoT and cloud. It emphasises how key features of fog help the system in achieving lower network influx, reduced latency, resource utilisation, and immediate data computation and storage because these services take place closer to point of data generation. This data can be immediately visualised/accessed and used to generate early warning


| INTRODUCTION
During the last decade, there has been a momentous progression in the field of computing. Cloud computing (CC) has been an astounding area of research item until a staggering advancement of smart things/devices called the Internet of Things (IoT) indicated the bottleneck of such a centralised archetype. The IoT has given boundless aspects of research drawing attention towards the decentralised archetypes. Every second around 130 'things' get added to the IoT. In 2019, the number of devices connected to IoT is roughly estimated to be around 27 billion. It is very interesting to note how much storage, computations, and real-time data analytics response will be able to entertain such oodles of things in the internet. Eventually, dispersed paradigms such as fog computing (FC) and edge computing (EC) found their way with a perception of furnishing the potential of cloud at the edge of network through overcoming most of the challenges faced by CC.
In 2014, Cisco coined the term 'fogging' or FC. The concept of cloud and FC are interlinked. It follows the nature, as in, fog is in close proximity to the Earth than clouds. Technically also, fog lies nearer to end-nodes, delivering down the cloud functionalities to the end-nodes [1]. Fog extends the cloud and has many edge nodes connecting directly to the endnodes; thereby, it brings CC functionalities to the edge/end devices. In the edge connectivity systems, FC has the topmost expansion of the principles of EC. In fact, FC focuses on portraying a thorough configuration for both vertical and horizontal allocation of resources following the cloud-things continuity [2]. Approximately both FC and EC are similar with a small distinction based on the positioning of the intelligence and processing power. While fog is mainly domain-specific, edge mainly operates for cellular/mobile devices. Both the intermediate technologies, EC and FC, push the processing power and the decision-making close to the IoT zone from where data originates.
With the exponential growth of IoT devices, it is very difficult to maintain the variety, volume, and velocity of data it generates hence compromising on the quality of service (QoS). Enormous amount of data (big data) is generated from the IoT devices. When such huge amount of data is sent to the cloud directly, it results in a massive network influx. If the FC layer is introduced between the IoT and the cloud, data processing becomes faster, storage becomes handy, and the resultant network influx decreases. Not all data is important to be sent to the network backhaul. Much of the data can be handled and computed by fog nodes, which improve the strength and performance of cloud architecture. Fog provides an empowerment to the cloud services but not a replacement. FC enhances the execution of exhaustive computations aid for the remote nodes as a portion of the data processing happens near the area where the results have to be conveyed to the user nodes. In this research work, a survey is made exploring a significant amount of research work in FC and other related technologies and frameworks involving cloud and IoT. Thereafter, the architecture, features, applications, and challenges of FC are discussed. From all these data, a novel technique has been proposed to monitorthe environment of open-cast mines in real-time with the integration of fog with IoT, cloud and sensors. A general overview of this unification is shown in Figure 1 depicting the basic elements. The three ingredients are (a) mines sensor network, (b) fog layer and (c) cloud layer. Factors such as ground vibration due to blasting, slope failure due to its movements, lorry positioning and mines personnel positioning could be monitored. Data produced from these factors are sensed by the sensors, which are deployed in this area and sent to the fog; then, the refined data is sent to the cloud layer data centre for permanent storage.
This proposal is detailed later in this manuscript. To sumup, it can be speculated that addition of fog upgrades the architecture of real-time monitoring systems, which do not prefer delay in data transmission. The following are the main objectives of this survey article: The rest of the research article is organised in the following sequence: Section 2 gives the motivation behind this research. Section 3 gives the background of the components used in Fog-IoT Mines Monitoring (FIoTMM) system, describes how FC aids IoT and CC and outlines the characteristics and architecture of FC. Section 4 shows the related research works. Section 5 compares the feature CC, FC, and EC. Sections 6 and 7 list the applications and concerns of FC respectively. Section 8 describes the proposed system. Section 9 lists the service latency analysis and performance evaluation of FC scenario as compared to CC. Section 10 concludes the paper with a future outlook. Thereafter, mathematical modelling is presented in Appendix section.

| MOTIVATION
Fogging is an emerging concept having great potential to implement energy-efficient strategies. The primary motivation behind this work is the need of latency reduction, fast processing of data in IoT applications, and reduced burden on cloud. In the existing mine monitoring system/applications, the fog layer is absent, which means that every time the sensed data has to be sent to the cloud, the monitoring system needs to wait for visualising the response until cloud has processed the data. With the integration of fog in the system composed of IoT and cloud, there will be hike in the overall system behaviour. The real-time monitoring applications usually involve cloud and IoT where latency is a major problem due to variety, velocity, and high volume of data. Due to huge amount of data, round-trip time delay is caused, which increases from milliseconds to seconds and then from seconds to minutes [3,4]. When it comes to monitoring of environment such as air, heat, rainfall, slope movement in mines, rock displacement, and precipitation. Data is uncertain and fluctuates every moment. Hence, it becomes very important to record every data and understand the exact flow or behaviour of that scenario. Moreover, a comprehensive survey of previous research stuffs has been surmised, and an attempt has been made to accomplish a real-time mine monitoring system. This will give another research perspective of FC in real-time environment monitoring.

| BACKGROUND
CC has seen a golden decade from 2005 to 2015. Despite the merits of cloud, CC is facing a shift in paradigm, and thus the concept of fog/EC came into spotlight. With the emergence of FC, the colossal load lifted by the centralised cloud framework has transformed closer to a point where the data is produced, that is, the IoT devices. When processing comes closer to the source of data, the response time becomes acutely low. Thus, this transition from cloud to fog travels also touches other technologies such as cloudlets, fog, and mobile edge computing (MEC) or EC.
Cloud computing: CC utilises core resources of the network. Cloud bears a centralised software and application server with a huge data centre and an inherent local network. Thus, it can maintain and store big data in a local medium that cannot be done by any IoT devices. This big data is not only useful for information but also important to know the trend it follows concerning a particular area which is commonly known as big data analytics. The IoT devices can neither process such a large volume of data nor store the ample computational data in its limited memory capacity. To overcome these shortcomings of IoT, CC provides service by connecting to the IoT. Iot devices generate data and send it to the cloud for processing and storage, and then, the processed data is sent back to the IoT layer as per the requirement. Due to growing number of devices, several requests to the cloud layer become more, thereby increasing network traffic and delayed data exchange with the IoT layer. Here the cloud functionality minifies and becomes less suitable for time-sensitive applications [5]. Ensuring the handiness of the CC performance, IoT framework faces a lot of difficulties such as data synchronisation, maintenance, standardisation, balancing, and privacy [6].
Internet of things: The term 'thing' can be any physical entity in this world, connected to internet, with a unique tag through which it can be identified. These things can sense and gather data of the parameters from smart home, atmosphere, environment, agriculture, military area, health care, transport, aircraft, appliances, and so on. Some of the sensors are: sensor to measure water volume to prevent water leakage in irrigation, sensor to measure water pressure to monitor its flow used for cultivation, pressure sensor to monitor pressure acting on vehicles and to resolve altitude in aircrafts, chemical sensors, biosensors, IR sensors used to observe health parameters, GPS, gyroscope, and proximity sensors used in mobile devices and vehicles. These sensors are not influenced by dirt, water, or oil. If such ample devices every time request cloud, then the network's bandwidth is decreased. Thus, fogging has to be utilised to filter the data sent to the cloud.
Fog computing: This archetype offers connectivity support for low latency, location-based and real-time services enhancing user experience. Maximum things in the IoT network demand time-sensitive, energy-efficient, and real-time aids. The fog nodes which are available as a middleware between cloud and IoT in a distributed fashion fulfil this criterion as they have effective data processing power and resource management as compared to cloud. In this way, the cloud functionalities are brought in close proximity to the network edge where data is generated through fogging. The fog layer wisely filters the IoT data into two categories. One class of data has to be processed by fog nodes and another class of data should be dispatched to the CC layer. Though FC is not a substitute for CC, it acts as an add on to the cloud features.
Both CC and FC offer sophisticated calculations and durable storehouse for data. FC utilises spare resources at the network edge to execute tasks.
Cloudlets: While fog is considered as a mini cloud, cloudlets are considered as micro cloud data centres operating in small scale [7]. This also extends cloud services like fog does. While cloud offers limitless resource usage, cloudlets can offer only finite resource usage. Cloudlets are situated at the internet edge. Mainly it supports resource-demanding mobile applications for mobile devices which can reciprocate by offering high power computing resources at a quicker pace [8]. These mobile devices can be tablets, smart wearables, smartphones within a closer geographical area.
Mobile edge computing: This technology also aims at enabling CC features at the network edge to improve QoS. MEC computes at the edge like the micro cloud node, or cloudlets can be an edge node between an IoT device and cloud [9]. MEC chiefly operates at the mobile network base station, and both computation and storage are regulated external to the mobile device. MEC and FC are interchangeable, where MEC addresses more of the things in the IoT layer, whereas FC addresses more of infrastructure sector [10].

| Fog computing to aid internet of things and cloud computing
When it comes to the scenario of (1) managing data, (2) processing data, (3) instant data analytics, and (4) quick resolution out of the evaluated data, the cloud being a centralised system and having powerful computation ability and capacity to handle and supervise a huge data is a perfect choice which can perform these four tasks efficiently and simultaneously. This goes fine when the 'things' in the IoT are less or concentrated within a smaller geography. Nonetheless, if the number of IoT applications or 'things' increases covering a wider geography, then to fulfil all the four tasks simultaneously is not possible for CC due to its concentrated nature. So, to have all four tasks done at the same time, rather than referring everything to the  cloud, there can be resources lying nearer to these 'things' that produce data. These resources can locally process the data collected from the 'things', and hence manage data; then at the same time it can analyse the data and send back a prompt response to the 'things'. Thus, this is a smarter way to utilise the resources and have instant response for the requests. Besides, another perk of this concept will curtail extra burden on the cloud servers because only cloud-compatible requests will be sent up to the cloud. These requests are the ones which are essential from the system's viewpoint based on the type of application. Apart from aiding the cloud layer, this concept also aids the IoT as not even a single 'thing' is left unattended. This concept is nothing but the FC paradigm.
Normally, the IoT applications, which need an outside computing source and storage, have the following four characteristics: (1) are distributed in a vast geography, (2) have a copious number of sensor nodes (SNs) for data transmission, (3) have huge data to be processed, collected, and made available for the next processes waiting to act upon, and (4) possess live data analytics. Each of the abovementioned features can be efficiently addressed by cloud but not in a concurrent manner. This is a notable challenge of CC. Another concept is that the connotation of the data investigated mostly depends on location when it comes to real-time data analytics. For instance, data generated by an event might be an insignificant universal degree but can be very meaningful for a local or intermediate process. Monitoring applications such as health monitoring, environment monitoring, or traffic monitoring operating in cloud-IoT blend, tend to fall under this category [11,12]. These applications have a lot of processes, and only the refined data should be stored in the cloud server for its permanent impression and ubiquitous availability [13]. Data analytics, predictions, and statistics can be computed upon this cloud data. The intermediate results are not needed to be stored in cloud because if not immediately, subsequently, local analytics and aggregation job must be done for the localised data [14]. Then, why not do the same in some local layer between IoT and cloud. Hence, to back both core layer and edge layer, fog becomes a bridge.

| Characteristics of FC
Besides gluing the cloud and IoT layer, fog addresses various other features described in this section as follows: Location cognizance: Fog nodes can be deployed anywhere in the fog layer. This technical component gives knowledge about the physical position of anything to another application [15]. Ultra-short latency: As the fog layer is closer to the edge of internet, processing occurs very quickly and hence turn-around-time decreases significantly giving very short latency [16].
Geographical distribution: As compared to the centralised cloud architecture, fog offers a distributed system for its applications thereby reducing congestion in network. The fog nodes are widely distributed over the IoT layer, so that they can accommodate all the data coming from the IoT devices [17].
Extensibility: Due to the distributed nature of FC, the fog nodes are sizable in nature. Thus, it supports implementation in large-scale edge devices. For environment monitoring systems, such large-scale sensor network is mandatory, which is scalable and extensible in nature [18].
Mobility support: Fog can connect directly to the mobile devices which can isolate location identity from host identity by using some protocols such as Locator ID Separation Protocol. This enables mobility schemes [16].
Real-time communication: While cloud offers batch processing, fog provides instantaneous processing in fog nodes [19]. This reduces delay and supports interaction in a timely manner.
Heterogeneity: Due to implicitly virtual structure, FC is adaptable in nature, and it can be deployed in any platform. Therefore, it goes with any type of application [20].
Interoperable: Fog can interoperate among a large scope of environment as it is compatible and reconcilable. This includes functions such as spontaneous streaming and ability for analysing and decision-making.
Privacy and security: When it comes to internet, everyone is concerned about safety of their information as it is uploaded in the cloud platform. As fog is distributed, central management of data is not possible. When fog processes, it is at an intermediate level, and the user does not have full authority over the fog application. Thus, it becomes very important to keep sensitive data securely. Many research works have proposed security solutions for fog services which ensure the reliability on fog network [21].
Resource/task management and scheduling: Management of resources and task is a very primary function of FC. Mainly when heterogeneous devices work together, it becomes essential that idle or spare resources are utilised based on their availability, so that system efficiency is improved. The tasks should also be allocated in such a way that throughput time is minimum, and resources utilisation is maximum while computing a task. If this is not managed properly, fog faces unwanted complicated problems while processing IoT data. This in turn will become an obstacle in lowering latency. Fog resources are not committed, and hence, available resources are efficiently allocated for processing [22].
Fault tolerance: This is the quality of a system to be ongoing even though a portion of the system stops working; it may be a hardware, software, or network breakdown. As a result, the system seems to perform as it is instead of closing fully. Fault tolerance is addressed in CC and should be addressed in FC as well. Many research works have given to consider this concept [23,14].
A very interesting mechanism known as duplication is commonly followed which replicates data from one fog node to another [15]. This serves as a data back-up and thus ensures data integrity.
Multi-occupancy: Multiple users use a service with a secluded run-time for an individual user known as multioccupancy. The users or devices are referred to as occupants within the network. This feature is important as count of resources is limited in fog layer. One occurrence of multioccupancy will serve multiple nodes to operate [15].
Real-time data analytics: Due to the placement of fog between the cloud core and internet edge, fog ingests and processes data closer to the Internet in real-time. This is also done by the real-time analysis [14].
Cognition: Fog framework is conscious of user requirement and thus intelligently manages the tasks and resources. It carries out fine execution of data and provides control, connectivity, and storage facilities as per the cloud fashion and hence improves service quality of the clients and end users [24].
Agility: To start a completely new framework from the scratch is an expensive task. In this context, fog supports the concept of create-respond-change popularly known as the agile development of an application. This service is less expensive and adaptable to any type of application in the IoT layer. Due to agile support, managing development of an application becomes more efficient [25].

| Architecture of fog computing
Fog bridges the gap between the cloud (core) and the IoT edges. The backbone of the cloud architecture are the database centres where large amount of data is stored and processed. The fog network contributes to faster data processing and decreasing response time and round-trip time to the cloud and back to the end devices. As shown in Figure 2, the fog network architecture is formed of three layers, namely (1) the IoT layer, (2) the fog layer, and (3) the cloud layer [26,27]. The following are the detailed working of each layer.
1. IoT layer: This is the bottom layer (also known as sensing or edge layer) which comprises of universally distributed sensor devices. It operates in the physical and data link layer of the network stack model. It consists of sensors as a part of sensing technologies making the base of the IoT layer [28,29]. Sensor devices could be smart home appliances; environment scenarios such as mines, rocks, water bodies; health care devices; smart devices; smart vehicles; fingerprint sensors; and manufacturing factories. The sensed data goes through some local processing before going to the upper layer. This layer collects data from the solely identified objects of the IoT network through the SNs, then converts this data to digital signals and finally transmits them upwards for further processing. The sensed data is communicated from IoT edge to the fog layer through communication mediums like WSN, Wi-Fi, radio-frequency identification (RFID) technology, long range communication technology (LoRa), Bluetooth, cellular technology like 4G/5G, and near-field communications (NFCs). 2. Middleware: This is the fog layer or the middle layer where the countless fog nodes operate for processing abundant data and produce refined evaluated data [30]. The fog nodes act as local servers having intense processing power. Fog layer consists of gateways, firewalls, access points, routers, cloudlets, and switches. The fog information is temporarily stored and transmitted to and fro the two end layers: edge and core, and this data can be easily accessed and visualised anywhere in between these two layers. Therefore, fog connects to the edge to receive data and also connects to cloud to produce and collect data or requests. Fog is also intelligent enough to filter out what data has to be sent to cloud and what data should be locally processed in fog. This reduces cloud overheads and improves all round system efficiency and cost-cutting. For time-sensitive applications, fog instantly computes the data and gives the result to the end user rather than waiting for cloud. This minimises latency. Specifically, for mining applications, where there is risk of losing human lives and equipment, even a little delay in generating early alarm may prove fatal. The importance and justification of introducing FC in mine monitoring application are elaborated in Section 11. 3. Back-end layer: This layer comprises of cloud data centres and network core layer. The cloud layer has numerous highperformance base stations with high storage capacity for permanent data storage. Main units of cloud layer are cloud servers, application servers and data centres. The data fetched from the IoT devices do not get stored directly in cloud server rather. They are refined in the fog layer, and then, that data goes to cloud to be stored permanently and be accessed through internet. The internet or World Wide Web acts as a connectivity between cloud and fog layer.

| RELATED WORKS BASED ON INTERNET OF THINGS AND FOG
With the growing demand of instant wireless connectivity in day-to-day life, FC is also actualised. Fog originates from the convergence of WSN, IoT, CC, EC and mobile computing [31]. It acts as a powerful tool to harness the resources in closeness to IoT so that both communication with cloud servers and provision of timely processing of data are obtained simultaneously. FC is very powerful tool when it comes to data to be collected at extreme edge like roadways, extreme environmental condition, vehicles, ships, smart cities and so on. Besides, when there is need to segregate data from a large number of devices across larger geographies. Most importantly, for time-sensitive applications which demands analysis and processing of data instantly having both time and resource constraints. Many research activities are going on in this field. Work done in [32] proposes a weight cost model which checks execution time and energy use of IoT applications. This algorithm ensures that tasks are processed concurrently. FC is also applied for privacy preserving data collection. Lu et al. have implemented lightweight data collection scheme which can exclude false data and endures fault tolerance [33]. Baccarelli et al. have combined both cloud and fog frameworks to ensure minimum computational energy during task and resource allocation using genetic algorithm [34]. Fog can accurately recommend contents while browsing in IoT based environment applying association rules [35]. Besides recommending content, abstraction of useful information can be done by recommender system based on fog [36]. A scientific research work for developing semantic model through guided approach has been proposed by Petrovic et al. for deployment and flexibility of containerbased operations in FC [37]. Proposal in Reference [38] describes a model for IoT applications to reduce usage of energy and processing/execution time; Memetic Algorithm is also proposed which decides which IoT application/s to be chosen to run concurrently in fog environment. Information-oriented service model is proposed for fog architecture for being auto-adaptive and operate in both cloud and edge devices [31]. To cope up with exponential growth of IoT data in cloud which is referred to as big data [39], it has become a pre-requisite to have a fog layer in between the IoT devices and cloud [40] in a smart home [41,42], or smart manufacturing system [43], or smart connectivity through gateway [44] or smart grid [45]. Even this big data is ubiquitously available from cloud server through the fog layer. When container is used as a resource in multiple cloud-fog architecture, servicing time of requests decreases [46].

F I G U R E 2 Three-layered architecture of internet of things (IoT)-fog computing (FC)-cloud system
Latency is most important factor for time-sensitive IoT applications. Fog infrastructure is scalable and hence the fog nodes adjust accordingly, work in synchronisation while processing data to reduce turn-around-time [47]. Another humandriven and device-driven intelligence approach applies machine learning and task-offloading algorithm which enables fog to reduce latency [48]. Service-level agreements (SLA) for IoT services can also be monitored using fog thereby bringing energy efficiency and profit to the users [49]. Fogging is also used for task scheduling of offloaded tasks preventing any miss in deadline by managing and predicting resources in such a way that tasks are distributed to under loaded or leisure fog nodes [50][51][52]. Task scheduling and resource management are two important features addressed by fogging in a better way than any other framework [53]. Resource allocation could also be done via physical fog kit to fulfil the need [54]. For multitier fog systems, offloading of workload is a challenge. Though it reduces latency, during network traffic, it may consume more energy for processing. Thus, systems having features like predictive offloading [55], computation with energy gathering capacity [56], ubiquitous availability [57] are useful for such scenario while allocating IoT resources in a cloud-fog-IoT environment. Vehicular task offloading could also be checked using 802.11p transmission protocol [58] and through fogging for sensing for self-driven vehicles [59]. To charge the electric vehicles, fog incorporated smart grid [45]; here fogging is used to minimise plug-in time in public charging points.
Data privacy and security is also an important feature addressed by fog [21]. In some studies, machine learning is applied to FC addressing security and resource management [60,61]; while some studies propose trust models combining cloud and IoT to enable privacy [62]. Agent-based encryption is implemented to put a check on access using unknown keyissuing protocol preserving user's identity [63].
While comparing cloud with fog platform and without fog platform, the former one proved that cloud with fogging helps increasing energy efficiency and reducing queue length of time averaged applications [64]. Drones are significantly used in different fields to capture data. Fogging is also applied here to compute the collected data locally to provide instant processing for applications like entity recognition, military applications, path planning, etc. [65]. Space applications are also time sensitive ones requiring intense computation and this is taken care by fogging in the form of satellite nodes [66]. Geographically distributed applications need fog integrated IoT system for effective monitoring [67]. Ensuring QoS is effectively maintained by fogging as task scheduling is optimal and hence response time is swift thereby decreasing cost [68]. In health care applications and services operated in IoT network, QoS is enhanced by fogging [69,70]. Besides QoS, Quality of Experience (QoE) is also improvised by fog. In Reference [71], application placement policy is suggested which is aware of placing applications appropriate for fogging.
Other miscellaneous applications like gaming also share resources that are unoccupied through fogging [72]. Mainly inexpensive and time-sensitive have a high requirement of fogging. There should be a balance between the fog nodes which carry out inexpensive and minimum latency services and the cloud nodes which bears costly processes. Therefore, load balancing of cloud nodes and fog nodes is crucial so that resource limitation is not compromised [73]. After coming across the literature work, a more detailed survey of research work and the aim of the research is summarised and depicted in Table 1. This table envisions several existing fog-IoT based research works. The main characteristics outlined are based on QoS, cost of development, deployment and maintenance the system, efficiency, security, monitoring systems built on fog, bandwidth, latency, storage space, resource or task management and their allocation, modelling and simulation, healthcare and load balancing. To summarise, most of the research works show efficiency of FC. Moreover, the research works show how introduction of fog layer minimises latency and hence can be applied to most of the monitoring systems which are time-sensitive. Security concerns are addressed in research works to ensure security of information.

| A VISION OF COMPARISON AMONG FOG COMPUTING, EDGE COMPUTING AND CLOUD COMPUTING
After understanding the factors based on which the concepts of fog, cloud and EC differ, it will give a clear picture of how FC can be a helping hand to most of the cloud-IoT applications. Besides, it should be known how the two similar concepts of FC and EC differ from each other and are different from CC.
Architecture type: Both FC and EC have dispersed architecture whereas CC has centralised architecture [13].
Architecture component: The physical building blocks of the EC and FC architecture are multiple edge nodes or fog nodes whereas the cloud is composed of data centres [149].
Server availability: In cloud, there are limited number of servers; often confined to less data centres but in fog layer several servers are available and are more scalable; whereas in EC, the servers are less scalable and less in number as compared to FC [13].
Services offered: As FC is distributed and locally present above IoT zone, it offers services based on specific domain of IoT device/application. EC is confined only to offer service to cellular network and mobile devices [88].
Amount of data processed: In contrast to cloud processing big data, fog and edge process small/less amount of data [114].
Cognizance of location: CC, being a centralised system, is never aware about the position or location whereas both FC and EC are aware of their location as they have distributed architecture and have a number of nodes [131].
Mobility: CC has limited mobility as it is centralised. Both FC and EC support mobility as they can directly connect to the devices at Internet edge. FC is a better choice for this feature as compared to EC [4].
Real-time connectivity and response: Real-time connectivity is supported by all the three computing architectures, but only difference lies in ability to respond instantly. FC has the YADAV ET AL. Nguyen et al.

Resource/ Task Management/ Allocation
Modelling/ Simulation Healthcare
-9 T A B L E 1 (Continued)

Load Balancing
Shubo et al.
Richard et al. [117] Aparna et al. [130] Te-Chuan et al. [132] Jihun et al. [134] Vasileios et al. [137] highest ability for real-time response to any IoT request while CC has the lowest ability as it suffers latency. Ability to respond spontaneously for EC lies in the middle of these two. Real-time response depends on latency. Higher the latency, lower is the response time and vice-versa [138]. Data storage and persistence: Cloud promises life-long span as it regulates and deals with big data. Both FC and EC offer short-term storage being an intermediate layer and performing intermediate data processing. This depends to the application or area they are operating for CC [137].
Data analytics and quality of computation: Both FC and EC have short-lived or temporary competence to analyse data, both being a middleware; but FC has high power computations whereas EC computes based on priority of the task. CC has permanent capability for data analytics, and computations are carried out based on category [25].
Count of end-users supported: CC is accessed by general internet users as it is accessed through internet. EC has mainly mobile users as end users. End users of FC are mostly users of industrial IoT devices [91].
Area of deployment: CC infrastructure is setup in an area owned by a cloud service provider. As it has huge servers and data centres, it is mainly kept indoors. FC system can be deployed in roadways, open fields, home, buildings, streets, railway tracks, etc. This implies that wherever Internet can be reachable, fog can exist in those areas. EC infrastructure must be positioned by specific service providers in specific areas [4].
Service providers: Tech giants like IBM, Amazon, Microsoft Azure, and Google are cloud service providers. Cellular network operators are service providers for EC. Intel and Cisco IOx are fog service providers [138]. Cost and energy requirement: As cloud bears several data centres, the cost of maintenance and energy consumption by the data centres are high. When it comes to fog or edge, nodes need less energy to operate and less cost to setup and maintain [111].

-11
Positioning: Both fog and edge are closer to IoT devices generating data and hence they are closer to the user. On the other hand, cloud layer is located far from the IoT layer [150].
By comparing the three platforms-CC, FC and EC-it obviously cannot be deduced that fog/EC can be an alternative for cloud. All three platforms have their own merits and demerits, and all have different contributions to fulfil the demands and aspects. The detailed comparison of CC, FC, and EC is outlined in Table 2.

| APPLICATIONS OF FOG COMPUTING
The following are the applications when it comes to FC being applied to different fields. As the remote data is processed closer to where these are generated, it gives real-time experience to users. Some of the pivotal applications which drive the FC paradigm are as follows.
Distributed delivery of content and caching: A large volume of video stuff of different formats and sizes are broadcasted every minute over the internet via live-streaming, gaming, upload, and download. In the internet, video content occupies the maximum traffic while being transmitted over content delivery channels. These channels can facilitate storage of heterogeneous data in cloud database and also distribute web content over various streaming servers situated in diverse networks. As the video content does not lie nearer to the users, they still face a lot of hindrance while viewing it due to jitter, network delay, and buffering [151]. Therefore, it becomes necessary to store the content nearer to network edge so that it can be quickly delivered based on users' demand. Fogging provides a virtual channel for content delivery and pre-caching the content on demand for the edge. Enhanced performance of web: When a website or a personal blog is created, obviously, the creators would like to have lot of viewers and visitors. If the website is slow, this would impact on both business as well as viewers and the popularity of the website will go down. On the other hand, popular websites have many unnecessary and unordered contents and often users do not prefer [152]. It is fogging that plays a background role in bringing the performance of web services to the vicinity of the user [153]. Basically the performance of internet or web is viewed in three dimensions: (i) optimisation of web content, (ii) improved browsing, (iii) faster web transfer.

Parameters
Computational offloading: In case of IoT devices having limited resources, this method is preferred. This technique retains processing power, storage space, lifetime of battery, etc. of the IoT resources. Mainly offloading is carried out for saving energy, minimising latency and maximising battery lifetime, resource utilisation, and QoE. The challenges related to computational offloading are (i) discovering the aspects that influence processes and decisions of offloading particularly for fresh use cases (ii) providing resolution for the heterogeneous and diverse concerns in applications as well as in platforms (iii) designing of lightweight blueprints that can operate in IoT/edge devices without any power constraints [154].
Agricultural applications: Agriculture or farming is another crucial prospect in our life. Iot has also proved its importance in smart farming and smart agricultural processes. This has helped farmers to accomplish more productivity as per the farming standard, water management, crop management, water and pesticide content monitoring, monitoring life stock health, and crops all in real time [155].
Smart cities and smart homes: Cities are the place of industries, business and commercial activities, and manufacturing units which provide employment and other services. The 'smart city' concept revolves around espousing the applications of IoT to enhance life style of people, infrastructure, cost cutting, innovation, and responsiveness of the cities. Some of the popular smart cities advancements are smart infrastructure monitoring, smart street lighting, smart water management, smart waste management, and smart energy management. Small power stations such as smart grid, traffic signals, logistics, and transport are a part of smart city. When connected to fog, these enjoy instant processing services [45,92,104,112]. Home appliances which have become a part of IoT can connect to fog and have processed data [41,42,84]. The real-time events taking place in cities are handled by big data analytics, which gives the actual picture of what is happening [156]. The role of fogging in big data analytics is already described earlier.
Vehicular connectivity: Mainly two types of vehicular communication are addressed, that is, dynamic/moving vehicles and static/parked vehicles. With regard to computation, first step is to gather data, second step is to analyse this surrounding data such as speed of vehicles, number of vehicles, and presence of any passer-by, and final step is to respond according to this surrounding. With the involvement of fog, data can be pre-processed when there is vehicle to vehicle communication, and this computation can be done faster than when cloud is involved and hence provide real-time or quick response. If every time cloud is involved for vehicular computation, then it would be very difficult to provide realtime feedback because more the number of vehicles, more the amount of computation required. Self-driving cars (SDC) are the future of smart vehicles. So, when it comes to SDC, these vehicles would require quick information of the surrounding so as to avoid any mishap. Many researches direct towards vehicular fogging [8,45,58,59,79,92,108,115,126,147]. Vehicleto-vehicle communication is achieved using fog-IoT infrastructure within the embedded computers in the automobiles.
Real-time big data analytics: Through platforms such as social media, IoT, artificial intelligence, and machine learning, architecture has moved from data consuming network to data producing network. These act as a source of big data that come in different sizes and formats, which are produced by the connected devices in the IoT network. Around 99% of this huge amount of data is disorganised, and only 1% of it is significant, which is used for analysis and decision-making. Thus, computation and storage of this complete big data in cloud are neither possible nor recommended. This transactional analysis and computation is performed at the fog nodes, and thereafter, cloud handles the business intelligence. As FC offers real-time delay-free services, data can be shifted from manufacturing plants to the logistics and monetary associations which need real-time data analytics [20].
Health care: The main idea of implementing IoT in health care is to have the patients perpetually connected to the doctors and the health workers. When the sensitive decisions are made within the device's range, it helps the information to stay secure within the realm. FC offers its own processing units which can process and transfer data the without bothering cloud services, for example, at the health workers' office or hospital, which bear the patients' records. The device will not store any data, but accessing and modification of this data are possible based on set of rules. The IoT devices interfaced in this web will link hospitals, pharmaceutical stores, and other stake holders with the same record every time any modification is needed for that record. The parties with this collaboration will also enjoy the ease of sharing data in a cost-effective, efficient, and secure way as cloud is not involved directly. Different sensors incorporated in the patient's device are used to monitor various bodily parameters and patient's body location. e-Health applications are time-critical ones demanding instant data processing. Factors such as heart rate, sugar level, and blood pressure are monitored by FC [3,4,11,69,70,85,86,99,109,122,130,136,139].
Simulation models: FC is also applied to form various simulation models where advanced programming and computations are involved for making fog structure more robust [157]. These models can involve machine learning, artificial intelligence, and so on. YADAV ET AL.

-13
Live video and gaming: As FC offers latency free service, video streaming performance is efficient without buffering and delay [158].

| CONCERNS OF FOG COMPUTING
Besides the impressive features of FC, it also faces some concerns based on the environment it is implemented.
User security and data privacy: To safeguard user data and IoT device data, proper encryption mechanisms must be followed to reinforce privacy. A vicious user might use a false identification while data is passed through the fog gateways and may hack the data in the fog nodes. As the fog nodes are set up at the internet edge, lot of up keeping cost is needed. Moreover, the cloud is very secure as compared to fog, but the security measures of cloud cannot be extended to fog due to architectural differences between the two. Many cryptography and authorisation methods have been proposed for this challenge [159].
Intricacy: While dealing with a sea of IoT devices, it is obvious that synchronisation is a difficult aspect because different IoT devices will have different system structure with respect to both hardware and software aspects [98]. Though fog is flexible enough for heterogeneous, at times it becomes complicated to operate.
Managing resources: Usually the fog nodes are like network devices with extra computing and storage capabilities. These devices cannot match resource scope of conventional servers. Thus, fog resources have to be wisely managed [26].
Computing delay: While collecting data, over-using the fog resources, computation delay occurs thereby lowering effectiveness of fog servers. Based on priority and mobility, the resources should be utilised, so that delay is avoided [160].
Energy efficiency: As fog layer consists of many fog nodes/devices, its framework is distributed, and often consumes more energy. This factor needs to be resolved, so that energy-efficiency is achieved [14].
Scalability: The count of IoT nodes will undoubtedly come in exceed at least a billion; and every object in the Internet pool needs storage, resource and computing power. Fog being distributed in nature should be able to scale and support with respect to provision of resource, computation and storage for these devices according to their criteria [161].
Being heterogeneous: The structure of every IoT device may vary depending upon its developer, functioning and so on. Some may have sensors while some may have actuators; some may have computation power, whereas some may have storage power. Therefore, IoT pool is always a network with dissimilar devices [129]. Fog nodes should be adaptable to these devices depending on their requirement for supervising and regulating such a network of things.
Being dynamic: Another criterion of the heterogeneous IoT objects is being able to change dynamically in both hardware and software aspects so that the system plan changes accordingly. Performance also changes when the architecture of IoT changes internally. Therefore, fog nodes should also synchronise and arrange the topology and allocate resources accordingly [156]. Figure 3 describes the flow of the proposed FIoTMM system. It shows the position and organisation of different components of the model. The mine's site is outfitted with various sensors to sense the parameters. Due to location awareness offered by fog, the location of these sensors is identified by the fog layer thereby helping to detect any significant fluctuations in the motif. This helps to draw a better conclusion about what is happening in that area and enhance system performance. The area between the fog and cloud is generally connected by WAN. Below are the three main components of the FIoTMM model, namely (1) sensing layer, (2) smart fog gateways, and (3) core layer.

| DESCRIPTION OF THE PROPOSED SYSTEM
Sensing layer: The first layer is composed of the sensors and actuators deployed in the monitoring site or area to monitor the parameters such as slope movement, ground vibration, and lorry collision or positioning. These sensors act as IoT nodes as they are connected to the internet to give live data. The sensed data and signals have ubiquitous recognition and connectivity. Three main areas can be monitored in opencast mines. The slope movement is monitored using a timedomain reflectometer (TDR) [162,163]. TDR acts as a sensor to sense the movements and shifts occurring in the slope. Slope movements are used to predict slope failure in open-cast mines. Ground vibrations can be monitored through an accelerometer sensor-ADXL345. Ground vibrations occur during blasting in open-cast mines. Collision of lorries is monitored through ultrasonic sensors so that a minimum distance is maintained between two lorries or trucks to avoid collisions. Data captured from these sensors are sent to the fog layer through wired or wireless network such as Bluetooth or cellular network or LoRa, ZigBee, and Wi-Fi.
Smart fog gateways: The next layer is the fog layer that receives the sensed data from the SNs through the edge gateways located at the fog boundary. As mentioned earlier, the fog is smart enough to filter out data, and not every data is sent to the core layer or the cloud for processing. Rather, fog takes care of all the latency-critical applications and realtime data analysis. As FC devices have limited storage capacity, this received data is temporarily stored for analysis and then required feedback is sent back to the source/ground devices. The SNs geo-spatially deployed in groups at each area to be monitored form their corresponding virtual cluster (VC). These VCs, are in turn, mapped to the fog instances (FIs) on one-to-one basis. Every FI is specific to a geographical location and serves its corresponding VC, having the SNs interlinked among themselves and connected to the internet. Depending on its location, the SN may join or leave any VC and thus get connected or disconnected to the FI. The FI scales itself accordingly based on the demand of SNs.
Core layer: The CC platform lies as the back-end core layer, which deals with big data and performs complex functionalities such as big data analytics and data warehousing, and the data is stored permanently and preserved for future reference. The data from cloud database can be accessed by the end users or clients from anywhere anytime through the internet using a graphical user interface. This big data is used for prediction of a particular scenario, research statistics, and analytics.

| APPLYING FOGGING TO MONITOR OPEN-CAST MINES IN REAL-TIME
In the field of mining, slope monitoring of open-cast mines, lorry monitoring, and blasting are the frequent changes that demand delivery of instant response of processed data from the server. In the blink of an eye, a collapse, or a roof fall, or a slope failure may occur in the mining site due to uncertainty of its environment. Therefore, the particular area of the mines' site needs to be monitored every second. This gives rise to bulk data to be stored in the cloud server. The faster the transmission of response, the faster ar the prevention measures that can be taken to safeguard the mines' personnel, equipment, dumper, etc., so that these do not get stuck during mine failure collapse. If there is any delay, the monitoring system will not be able to visualise and analyse the scenario, thereby making the situation worse. It is not feasible on the cloud framework's part to provide processing of data and instant response to the request made by the IoT devices simultaneously. Hence, there is a need to implement an intermediate fog layer as a communicating gateway in between the cloud server and the sensors deployed in the mines' site. In this regard, the service latency is found out, and performance of the proposed system is evaluated.

| Service latency
Total delay is the sum of transmission delay and processing delay. Let Δ IF and Δ FC be the average delays in transmission of a data packet from a SN/IoT device to the corresponding fog node and from the fog node to the cloud data centre respectively. Thus, the mean transmission latency, ρ Fog for the data packets of A i application instances running within fog node F i is given by where B i and b i (B i > b i ) are the total number of packets sent cumulatively by A i application instances to fog node (FN i ) and from FN i to cloud data centres respectively. The processing latency of a data packet at a fog node is ψ F and ψ C at the cloud data centre.
Total processing latency in fog-cloud is given by where The latency expression in tradition CC scenario is given by where Δ IC and ψ C is the transmission latency and processing latency, respectively, of a packet from sensor device to cloud data centre.
The latency expression in fog is given by Total latency

| Performance evaluation
Based on the mathematical model described in appendix, performance of FC is evaluated and compared with the traditional CC method. 10 FIs were considered connected to one cloud service provider. It is assumed that VCs consist of SNs that are evenly scattered. MATLAB R2014a is used as an experimental platform based on Intel (R) Core (TM) i7-4770 CPU with 4 GB RAM at 3.40 GHz which runs on Linux (Ubuntu 16.04.3 LTS). The size of the instruction is 64 bits. The user-fog link allows packet transmission of 3464 kilobytes following Poisson arrival pattern. Its instruction size is 8 bytes with mean packet arrival rate being one packet per node per second. The link capacity between the source of data generation and the fog node is taken as 1 Gbps and the inter-fog communication link capacity is taken as 10 Gbps. This experiment is repeated 20 times, and average is taken to avoid the influence of uncertainty factors on the outcome of the experiment. The percentage of applications which need cloud access is varied and the average latency for all the nodes within a VC is plotted against a variable count of SNs. Figure 4 shows that with decrease in count of fog nodes, there is an increase in the average latency. The average latency is observed to be less as compared to the traditional CC method. In Figure 5, 75% of the data is processed in fog nodes, whereas the remaining in the cloud. Here the number of fog nodes are varied as 2, 4, 8, and 10. With the increase in the number of fog nodes, the average latency reduces.

| CONCLUSION AND FUTURE SCOPE
FC has just passed its inception stage and is currently being probed at different angles. Instant computation and storage availability are the need of the hour, and FC has entered the world of computing during such a favourable time that it will emphatically influence the working cost of the clients and the end users due to cutting down of the setback suffered during time-critical applications. In this manuscript, a literature on FC and the analogous concepts are surveyed. The survey of a variety of research studies done infers that for raising an extensible and scalable base for IoT with the edge devices, a smart, credible unification of CC and FC is required. This amalgamation could be efficiently applied to monitor scenarios in open-cast mines' site. Many varieties of monitoring systems could be developed based on FC.
Moving towards the future direction of FC as applied to the field of mining, this blend of FC and CC has to be implemented in open-cast mines with field observation. The main focus will be on field monitoring of slopes in open-cast mines. This observed data has to be modelled and performance evaluation has to be computed to study the scenario more accurately and generate early warnings in the case of a slope failure. From this survey, it can be evidently contemplated that fog serves as a rationally wise platform to regulate and supervise the widely scattered and real-time quality of the looming IoT paradigm. When fog is combined with IoT infrastructure, new business working models could be developed and the existing models or systems could be reconfigured with FC resulting in a new research direction. Fogging seems attractive for some of other applications too, as described in this work. With respect to resource-limited and latencyconscious applications, fogging offers a more affluent platform. So far as the standards are concerned, fogging goes in harmony with the IoT products. FC combined with machine learning and artificial intelligence will expedite its development and make the existing fog systems rich in the future.

| APPENDIX
Mathematical model of the system: The mathematical description of FC architecture is given in this section based on the operational functionalities and its composite objects. Two assumptions were taken while formulating the mathematical modelling. First, the total number of SNs installed in each of the monitoring areas is assumed to be fixed with respect to time; and second, it is assumed that there is no packet loss in the network. The SNs in this network can monitor various mine activities such as slope deformation, ground vibration, and lorry collision etc. These SNs are clusters of TDR, accelerometer, and ultrasonic sensors. The total count of SNs traversing over all VC in the primary layer is assumed to be fixed with respect to time [149]. Furthermore, the VCs offer entire coverage for all the SNs up to the bottom most layer.
N is taken to be a set of x numbers of static SNs installed randomly over an area of a�b in open-cast mine. A single SN is denoted by η ∈ N, defined as 10 rows. In the above equation, the unique IDs of SNs are denoted by an integer N id . N st represents the status of a SN. The set N st = {0,1} indicates in the Boolean form if the SN is active (symbolised by 1) or inactive (symbolised by 0). The event type sensed by a SN is indicated by(ν i ). It can be mathematically represented as an element of the set ν ¼ fv 1 ; ν 2 ; ::::; ν n g. Here ν stands for the set of all events that the SNs monitor, and the total number of unique events is denoted by n. The hardwares like LoRa, ZigBee, Bluetooth, etc. used by the SNs for communicating wirelessly are denoted by the row N c . The range of frequency at which the SNs operate is denoted by N f . The battery level of a SN is given by N b . The SN stops communicating once the N b value drops below the threshold value. The location of a SN is denoted by N l . The processor specifications of the SN are denoted by N p . These specifications consist of details such as specifications of bus, speed of processing core, and size of cache memory or internal register. Lastly, the cluster ID of a SN is denoted by N cid . The last row of SN definition is an 1D array κ[p] (having p elements). It holds the instance IDs of the application instance (AI)s which are currently running on the device. An AI exists only in the presence of a parent application in a device.
The application A has two tuplesis given by; Here the application ID is denoted by A id and A s represents the system requirements needed to run the application that includes operating system version, storage details for both primary storage (RAM), and secondary storage (ROM) and processor details. The AI has five tuples given by; AI ¼ < AI id ; N id ; A id ; AI r ; AI s > Here AI ID is denoted by AI id that is similar to a system generated process ID. N id and A id have the same designation as mentioned earlier. The resource requirement of the AI in terms of computation, network bandwidth, and ability to analyse or process and storage power is denoted by the tuple AI. More than one instance of an application may simultaneously run on a SN, and are identified by their unique instance IDs. AI s is a Boolean variable, such that AI s = {0, 1}, indicating values 0 (inactive state) and 1 (active state) of the AI. A VC, designated by V, is a logical boundary consisting of many localised SNs, and represented mathematically as four tuples; Here ID of VC is denoted by V id , and V d [m] is a single dimensional array of size 'u' that holds the IDs of all the SN constituents. At any given point of time, the array length changes dynamically which indicates that the count of SN in the VC may leave or join the VC altering the array length.V r denotes the region monitored by a VC including all intermediate SNs. For SNs to be able to monitor effectively, the geographic terrain is divided into many non-overlapping regions and each region is mapped to a VC. The physical FI to which a VC is mapped is known by F id . Mathematically, (I ) denotes a FC instance or FI which is defined by three tuples.
Here F id is the unique ID of FI, and F ap is the access point which connects the FI to the core CC framework. Third, F [x] is a single dimensional array of size v which holds the device IDs of all the constituent FC devices of a FI. A FC module is denoted by M, based on its type and characteristic features by three tuples; Here M id and M type are the ID and the type (such as gateway, router, processing unit, or storage) of the FC device. M s tuple stores the related specifications and hardware of the fog device.