Fog Computing

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.7illustrates 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.

The context represents the runtime factors that influence the server operation and the applications. In general, the context of MFC involves the follows:

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.

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.

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 context 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.

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.

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.