on the state-of-the-art literature in both iFog and mFog across the four MFC domains, we explain the elements of the five aspects and what needs to be addressed in order to achieve the QoS in MFC.
1.5.1 Heterogeneity
There are three types of heterogeneity: server heterogeneity, end-device heterogeneity, and end-to-end heterogeneity.
1.5.1.1 Server Heterogeneity
Different to the common IaaS/PaaS-based cloud services, which are virtual resources, fog services are hosted on resource constrained physical equipment that has limited computational power and networking performance. Therefore, when tenants intend to deploy their applications, they need to consider the compatibility, connectivity, interoperability, and reliability of the fog servers. Specifically, we can classify the heterogeneity of the fog servers into two aspects: hardware type and software type.
Hardware type. Represents the hardware component specification and configuration. In detail, the provider should clearly provide information on the hardware in terms of the computational resource specifications, such as CPU model code and speed, RAM model code and speed, read/write speed of storage, independent or integrated GPU, vision processing unit (VPU), field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), AI accelerator, etc.; the available networking resources specification, such as IEEE 802.11a/b/g/n/ac, Bluetooth LE, IEEE802.15.4, LoRa, NB-IoT, etc.; extra components such as inbuilt or connected sensors that are accessible via the API provided by the fog server. Furthermore, if the fog server is hosting on a mobile Fog node, the provider should also provide the corresponding mobility-related information, such as the route of its moving path, the moving speed, and so forth.
Software type. Denotes the software application deployment platform supported by the fog server. For example, the fog server may support VM-based service which allows a flexible configuration. Alternatively, the fog server may provide a containerization-based platform service, such as Docker (https://www.docker.com). Whereas, for the resource-constraint devices, which can serve only a limited number of requests, the provider may configure a FaaS-based platform that allows the tenant to deploy functions on the fog servers to provide microservice to tenant-side clients instead of the completed applications.
1.5.1.2 End-Device Heterogeneity
The heterogeneity in hardware specification and the software specification of the end-device/user influences the overall QoS and QoE that tenant can provide. In order to achieve the best QoS and QoE, tenants need to choose fog nodes that are most compliant and most efficient for their end-devices. Specifically, end-device heterogeneity involves hardware specification in terms of the type of the device (e.g. smartphone, mobile sensor, drone, etc.), and computational power and network capabilities, which influence how the end-device/user interact with the tenant's fog applications deployed on the provider's fog server. Further, from the software specification aspect, the tenants need to consider what software they can install at the end-device/user-side and how well the client-side software may perform when it interacts with the fog nodes?
1.5.1.3 End-to-End Network Heterogeneity
The end-to-end network heterogeneity involves the three aspects listed here, and all of them would influence the performance of the other nonfunctional requirements.
Device-to-fog (D2F). Represents the radio network and the communication protocol used between the fog server and the end-device. In general, D2F has a broad range of networking options and hence, increase the complexity from the perspective of both fog server provider and the tenant. For instance, radio network options encompass IEEE 802.11 series, IEEE 802.15.4, Bluetooth, 3G/4G cellular Internet, LoRa, SigFox, NB-IoT, LTE-M, 5G New Radio (5G NR), and so forth, which indicates that the provider may need to support multiple radio networks in order to fulfill multitenancy. On the other hand, tenants also need to consider the available radio network provided by the fog server in order to optimize their applications.
Fog-to-fog (F2F). Represents the communication network between fog nodes in both horizontal and vertical manner. For example, Figure 1.7 illustrates the vertical communication between two LV-Fog nodes, while both LV-Fog nodes also rely on an iFog node to interconnect them to the cloud. Explicitly, the F2F network would highly influence the performance of the tenant-side application, especially when the application requires a certain process or decision making from the cloud.Figure 1.7 The three types of end-to-end networking.
Fog-to-cloud (F2C). Represents the communication network between the fog node and the cloud, which has a similar influence as F2F to the tenant-side applications. In particular, depending on the underlying infrastructure, geo-location of the cloud and the intercontinental routing path between the fog node and the cloud, the latency between the end-device and the cloud can be very different. Therefore, besides the D2F and F2F, the tenant also needs to consider the F2C network, especially when the application is unable to operate fully in a self-managed manner.
1.5.2 Context-Awareness
The context represents the runtime factors that influence the server operation and the applications. In general, the context of MFC involves the follows:
1.5.2.1 Server Context
Server context influences the serviceability and sustainability of the fog server. Specifically, it involves the following runtime factors:
Current task in queue and the task types [24]. Regardless of the end-to-end communication latency between the tenant-side client and the fog server, the task in queue and the task types are the factors that influence the response time of a tenant-side application deployed on the fog server. In particular, if a fog server has a large number of resource intensive computational tasks in the queue, its response will be much slower than a fog server, which has a decent number of simple tasks in the queue. In addition, the complexity of the task is a relative factor depended on the performance of the fog server.
Energy [62], which is a specific context factor for mobile fog nodes that rely on battery power. For example, UE-fog node and UAV-fog node are commonly operated based on battery power. Hence, tenants need to identify the sustainability of the mobile fog nodes before they decide to deploy the application on them for serving the tenant-side clients.
1.5.2.2 Mobility Context
Mobility context includes a number of movement-related factors that influence the accessibility and connectivity between the tenant-side client and the fog node. In particular, mobility context includes the following elements [27, 62, 63]:
Current location and destination, which represents the current physical geo-location and the destination of the tenant-side client and the fog node, which are the basic parameters to identify the potential encounter rate between the two nodes, based on measuring the possible movement routes.
Movement, which includes the moving frequency (i.e. how often the entity is moving), maximum and average moving speed, acceleration rate (i.e. moving speed of a specific time), moving direction, moving path, and route. Specifically, the system requires continual up-to-date information of these factors in order to adjust the mobility context reasoning.
1.5.2.3 End-to-end Context
The end-to-end context represents the factors that influence the communication performance between the tenant-side client and the fog server. Essentially, a system can measure the end-to-end