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.

       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.

       (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].