based on the server context and mobility context. Hence, one can consider that the end-to-end context is a second level context. In summary, end-to-end context involves the following factors [26, 64]:
Signal strength. A dynamic factor at run-time in many cases, such as LV-fog and UE-fog environments where the density of the wireless network objects is high and hence, they can interfere the signal strength of one another. Therefore, tenants need to consider the signal strength when they intend to measure the connectivity between the fog server and the tenant-side client.
Encounter chance and Inter-contact time. Represent the possibility of the fog server and the tenant-side client to successfully communicate and how long they can maintain the connection for the current stage and next stage. Specifically, it influences the decision of whether the tenants should deploy the application on the fog server for their clients or not, and whether the tenant-side clients can utilize the fog servers for task distribution or not.
1.5.2.4 Application Context
Application context influences the server-side performance and also the tenant-side decision regarding where the application should perform the task. In some cases, the process involves handling large amounts of sensory data locally at the tenant-side client, which could be more energy efficient than distributing the task to a fog server, because the involved data size is too large for the tenant-side client to transmit it to the fog server effectively. In summary, application context involves the following elements [28, 64]:
Request data type and the amount of data. Determines the complexity of the request from the perspective of the computational power of the tenant-side client and the fog server.
Deadline of the task and task priority. Determines the required time to complete the task derived from the tenant-side client. In general, it is a part of the service level agreement (SLA), which specifies that the fog server should adjust the tasks in its queue when it needs to prioritze some tasks.
Energy consumption of the client. Which represents one of the major costs of the tenant-side client, when the tenant-side application demands that the client relay the data to its encountered fog server for processing. As mentioned previously, in some cases local processing at the tenant-side client can be more energy-efficient. Hence, the tenant needs to consider the optimal energy efficiency for the clients in the application management.
1.5.3 Tenant
The nonfunctional requirements of tenants, who are responsible to manage the fog applications, aim to achieve the adaptability of runtime fog applications that involve both application services deployed on the fog servers and the application clients operating on the end-devices. In order to comply with the dynamic MFC environment, tenants need to address the adaptability at each phase of the application management. In general, the management of fog applications, which fundamentally are process management of IoT applications [65], encompasses three basic phases: (re)design, implement/configure and run/adjust.
1.5.3.1 Application Management
(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].
1.5.3.2 Cost of Energy and Tenancy
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.
1.5.4 Provider
The multi-tenancy-supported fog server providers