Fog Computing

(Re)design phase involves the software architecture design and the application process modeling design. Specifically, in MFC, tenants need to consider the adaptivity of their software architecture in terms of self-awareness and deployability. Self-awareness assures that the applications have corresponding mechanisms to identify the situation of the runtime application (e.g. the movement of the end-device or the fog node) and are capable of optimizing the process model automatically with a minimal dependence on the distant central management system. In order to fulfill this requirement, the architecture design may need to support decomposition mechanisms that allow the applications to move the processes of applications or even portions of a process (i.e. tasks) from one node to another node dynamically at runtime.

Implement/configure phase represents the stage that transforms the design abstraction to the executable software and deploying the software to the involved fog nodes and end-devices. In contrast to the classic static IoT systems which do not need to frequently adjust the location of application services, in MFC, based on the runtime context factors of the fog nodes and end-devices, the tenant needs to support the rapid (re)deployment mechanism in order to allow the fog applications to move the processes among the fog nodes toward optimizing the agility of the fog applications. Essentially, the rapid (re)deployment mechanism requires a compatible technical support from the fog infrastructure providers, considering the heterogeneity and dynamic context factors of the fog nodes, the tenants also need to develop the optimal decision-making schemes specifically for their applications in order to deploy the applications to the fog nodes in an optimal manner.

Run/adjust phase represents the runtime application and capabilities of autonomous adjustment based on contextual factors. In general, MFC applications need to support three basic mechanisms and consider two cost factors:Task allocation. Represents where the tenants should (re)deploy and execute their tasks. In general, unless the entire system utilizes only iFog nodes, MFC applications are rarely operating tasks at fixed locations. Therefore, while the mFog nodes or the tenant-side clients are moving, the fog applications need to continuously determine the next available fog nodes for the clients based on the contextual factors and the specifications (see previous descriptions) in order to rapidly allocate and deploy the tasks to the fog nodes.Task migration. Has a slight similarity to task allocation in term of (re)deploying tasks at fog nodes. However, task migration can involve much more complexities. For example, in a stream data processing-based fog application, when the client encounters the next fog node while the previous process is in progress, the previous fog node may try to complete the task and then intent to save the process state and wrap the result, the process state information together with the application software (i.e. in case the application is not preinstalled at all the fog nodes) as a task migration package toward sending the task migration to the next encountered fog node of the client. However, there is a chance that the routing path to the new fog node of the client does not exist, which leads to failure of the task migration procedure. Certainly, the example has illustrated only one of the failures in task migration. In order to support the adaptability at the run/adjust phase, the tenants need to consider all the contextual factors and heterogeneity issues in supporting adaptive task migration.Task scheduling. Represents the timing of any action at the run/adjust phase. In general, based on the application domain, task scheduling can involve different actions including the schedule of task allocation or task migration. For example, in Marine Fog [28], the system needs to identify the best time to route the marine sensory data among the ad hoc network nodes in order to deliver the most important information on time. For example, in LV-Fog, each vehicle needs to perform local measurements in order to identify the encounter and the intercontact time between itself and the incoming vehicle, toward performing rapid information exchange [64].

Besides the process and task management aspects, tenants need to consider the cost of energy and tenancy. First, energy cost commonly refers to the energy consumption of battery-powered end-devices. Here, the tenants should optimize the application design and the runtime processes in order to minimize the energy consumption of the end-devices toward extending the sustainability of the overall processes.

Second, the cost of tenancy indicates the cost-performance trade-off of the application. Specifically, in some cases, the tenants intend to achieve the best agility in terms of task allocation, execution, and migration, they would pre-deploy the application at every single fog node that potentially will be encountered by the end-devices. For example, in the AAL-based application, the tenant might have deployed the application at all the fog nodes on the potential moving path of the patient in order to perform proactive fog-driven sensory data reasoning [18]. However, such an approach may demand a high tenancy cost for the tenant, especially when we consider that the patient (the end-device) may not encounter some of the fog nodes.

The multi-tenancy-supported fog server providers are responsible to provide adaptive application deployment platforms for the tenants and to cater reliable accessibility to the tenant-side clients.

In order to achieve high QoS for the fog servers, the providers need to address the following aspects.

The physical placement represents where the providers should deploy their fog servers. Commonly, in the case of iFog, the provider may enable fog servers on all the possible nodes (e.g. cellular base stations) and rely on the underlying communication technologies (see Section 1.4) to support the accessibility. On the other hand, in case of mFog [24, 63], providers need to identify the best geo-location to place the mobile fog nodes in order to provide the best QoS to the end-devices and also to support the cost-efficiency of the operation. For example, in UAV-Fog, the provider may choose the locations for the mobile fog nodes based on the density of the end-devices, the signal coverage of the fog node, the distance between the fog server and the end-devices, and the other context factors described in the previous content related to context-awareness. In general, the primary goal of physical placement is to achieve the lowest latency in terms of request/response time, application service handover time, and application task migration time.

Server discoverability is a specific requirement for the multitenancy fog services, and it involves two phases.

Multitenancy fog service provider discovery. Presents the phase when the tenants intend to discover feasible fog service providers for deploying their applications. Commonly, based on the experience of the cloud service business model, it is likely that the tenants would discover the providers via the indexing services (e.g. Google searching). Alternatively, the providers may establish a federated service registry for the service discovery. Furthermore, the provider may follow the open standard-based service description mechanism or interface (e.g. ETSI – MEC standard) to describe their fog services toward helping the tenants to discover the service that matches to their requirements.

Runtime fog server discovery. Presents the runtime service discovery phase for the fog applications. In general, the fog applications hosted on the fog servers, need to perform seamless interaction with the end-devices on the move. Besides the mobility schemes that help the tenants to identify the movement of the end-devices, tenants need a corresponding mechanism that can help the end-devices to continuously discover and to connect to the new fog servers automatically, without any inference from the end-users. Therefore, the fog servers need to support the corresponding API that allows the tenants to configure the application process/task handover and migration mechanism among the fog nodes. Commonly, if such an API support is not available, tenants have to enable the corresponding mechanisms from the higher layer of the application, which may result in an inefficient tenancy cost and operational performance.