Fog Computing

In general, fog servers have limited resources in which they can serve a fairly limited number of tenant-side applications at each time slot. Therefore, fog servers require dynamic and optimal mechanisms to support their serviceability. Here, we list the basic elements involved in the operation management of fog servers.

Load balancing of request and traffic. Commonly, fog servers are connecting with one another vertically or horizontally. Therefore, it is possible to establish a cluster computing group among the fog nodes connected in 0-hop range toward enhancing the overall computational capability. Besides the computation-related loads, since fog nodes are fundamentally Internet gateway devices, the heavy network traffic can always affect their serviceability. In order to overcome the traffic-related issues of fog servers, the provider may configure multilayered caching mechanism that utilizes the fog nodes in the hierarchy to reduce the burden [66].

Server allocation, server scheduling, and server migration. Three corelated elements, especially for the resource constraint mobile fog node (constraint mFog), such as UE-fog and UAV-fog nodes. To explain, a provider may deploy a specific type of fog server on the constraint mFog device for a domain-specific application in a specific period of time. Whereas, the rest of the time, the device does not operate the fog server at all. For example, in an indie fog environment [17], the owner of a smartphone (UE)-fog may configure the device to serve the context reasoning–based fog server [36] only when the owner is carrying the device in outdoor areas and the battery level of the device is over 50%. Further, the owner can also configure that, when the battery level of the device is between 51 and 70%, it will redirect/migrate the request to another authorized fog node. Similarly, the notion described here is applicable to other MFC domains, such as LV-fog [24] and UAV-fog [63].

Operating fog servers can be costly for the providers especially when the providers are unable to identify what tenants really demand. For example, stream data filtering is a common method used in fog computing and the corresponding program can be quite simple in comparison to the scientific programs operated on the cloud. However, in the classic approach, the tenant may need to wrap the simple program to a package that runs on the resource-intensive VM environment because the provider was following the classic cloud service deployment approach to providing the fog server. Explicitly, the provider has inefficiently increased the burden of the fog node while providing excess service to tenants who demanded only a simple method. Therefore, the provider should consider what are the most cost-efficient service types that should be supported by the fog servers. Beside the service type, the providers of the battery-powered mobile fog nodes need to specifically address the energy-efficient of the fog servers in order to improve their sustainability. For instance, although providers can easily replace UAV-Fog nodes, considering the extra latency derived from the process/task handover and migration while replacing the UAV-Fog nodes, frequently replacing UAV-Fog nodes will reduce the QoE for the tenant-side clients.

In large-scale MFC systems, the classic perimeter-based security approach will not suffice, security strategies in MFC must account for various factors: physical, end-to-end, and also monitoring and management.

Since the fog nodes will be deployed in the wild (e.g. road-side infrastructure in LV-Fog), physical exposure is a more serious threat than in conventional enterprise or cloud computing. The devices need antitamper mechanisms that prevent, detect, and respond to intrusions, while simultaneously considering how to allow maintenance operations without compromising these mechanisms [61].

End-to-end security is concerned with the security capabilities of each device within the MFC, spanning different layers of the fog architecture and devices therein.

Execution environments. The devices need to include capable software and hardware components solely dedicated to performing security functions (so-called roots of trust (RoT). These components should, on one hand, be isolated from the rest of the platform while also verifying the functions performed by the platform.Based on RoT-s, the nodes must have the capability to provide trusted execution environments. In the case of virtualized environments, this can be achieved through virtual trusted platform modules.

Network security. According to the OpenFog security requirements, fog nodes should provide the security services defined by the ITU X.800 recommendation by using standard-based secure transport protocols.Some nodes in the MFC system can provide security services on the network through network function virtualization (NFV) and SDN, for example, deep packet inspection.

Data Security protection of data must be taken care of in all the mediums in which data may lie or move: in system memory, in persistent storage or data exchanged over the network.

The system must be capable of observing security state in the network and reacting to new threats via monitoring and management mechanisms. Security management should allow definition and updating of security policies and propagation of the policies over the network in real-time.

In addition to policy management, identity and credential management is a requirement. In addition to the necessary registration and credential storage functions, an MFC system must handle the challenge of authentication and access control in situations with intermittent connectivity, e.g. negotiating session keys when crossing different trust domains while ensuring data integrity and privacy [67]. Security monitoring, on the other hand, should collect log traces while ensuring their integrity.

The OpenFog security requirements define at least two logically separate security domains: (1) policies concerning the collection of Fog entities within the system that can interact with one another and (2) for policies regarding the individual services and applications being executed and provided on the platform.

Managing trust. The information flows in MFC raise the issue of how to determine which nodes in the network are trustworthy for a particular client and request? Trust management frameworks need to manage trust assessment of both devices and applications and be able to adjust to the real-time updates of trust-related data, such as social relationships and execution results [68]. Some scenarios may also require decentralized trust management achievable with the help of blockchain technology; however, this aspect has issues with latency [69].

Multitenancy. As the fog architecture dictates that fog platforms can host services for multiple parties, this poses the issue of how to ensure isolation in the runtime environment and ensure that only data that was intended to be shared is available across the instances [61, 70]. Secure isolation of tenant and user space continues to be a challenging requirement, as vulnerabilities allowing adversaries to access memory of other tenants VMs without permission [71] have surfaced, even in mass-produced CPUs.

Fog computing has been introduced to overcome many challenges that cloud computing was incapable of handling, such as latency-sensitivity, connectivity between the large set of cloud-based applications, etc. Therefore, many researchers investigated and proposed different architectures for introducing fog computing into the traditional cloud computing to create an extension of the existing design. This action resolved into solving some of the old obstacles and generate new perspectives and ambitions that led to new challenges.