Fog Computing

Low-power wide-area networks (LPWANs) long range (LoRa) has been receiving attention lately as an energy-efficient, long-range wireless technology. In the mF2C project [29], the physical layer-LoRa, accompanied with LoRaWAN at the data link layer is used for ship-to-ship communication, while [59] use it for ship-to-shore communication in harbors. LoRa with LoRaWAN can cover up to 15 km in rural areas with a data rate up to 37.5 Kbps [60], making it a lower-energy alternative to VHF.

Sigfox and NB-IoT can be considered as competitors to LoRaWAN. While LoRaWAN and Sigfox operate in unlicensed bands, NB-IoT operates in licensed frequency bands.

Dedicated short-range communications (DSRC) is another technology defined especially for VANET, which are one-way or two-way short-range to medium-range wireless communications designed for allowing V2V and V2I communications. It is characterized by its frequency of 75 MHz licensed spectrum in 5.9 GHz band, which is provided by Federal Communications Commission (FCC) in the United States [20, 26].

An MFC system needs to address a number of nonfunctional requirements in order to achieve the basic quality of service (QoS) principles. In order to provide a comprehensive guide to the developers, this section describes the nonfunctional requirements in five aspects – heterogeneity, context-awareness, tenant, provider, and security.

Figure 1.5summarizes the elements of the five aspects of the nonfunctional requirements. In general, the five aspects are corelated to one another. For example, heterogeneity is a common factor that needs to be considered when the fog tenant plans to choose which fog server to use to deploy their applications. Similarly, context awareness, which represents the runtime factors, is also influencing the decision of when and where to deploy and execute the tasks. Furthermore, the tenant-side end-device or end-user (i.e. tenant-side clients) is influencing the decision of how the provider of fog servers manage the fog nodes. On the other hand, the QoS of the provider's fog nodes also influences the decision for the tenant to choose the right fog node for tenant-side clients. In addition, although all the four MFC domains involve the five aspects, the complexity level of each aspect in a different domain can be quite different. For example, an application scheduling scheme designed for LV-fog may require significant adjustment when the developers intend to apply the scheme to UAV-fog because the heterogeneity level and the context factors are very different between the two domains.

As indicated above, we distinguish the tenant and the provider in which the providers represent the owners who own the fog server machines and are providing the fog infrastructure and PaaS to application service providers known as the tenants in a multitenancy manner [61]. For example, a telecommunication company such as Vodafone may host fog servers on their base transceiver station (BTS) and enable the accessibility of the fog server via 4G/5G/5G NR ( https://www.qualcomm.com/invention/5g/5g-nr) communication. Therefore, application service providers can tenant the fog servers and deploy fog-based applications on the servers toward serving the tenant-side clients. Correspondingly, Figure 1.6illustrates the relationships among the involved entities.

Figure 1.5 A taxonomy of non-functional requirements of mobile fog computing.

Figure 1.6 Fog infrastructure service provider, fog service tenant, and tenant-side clients.

Note that although, in a general perspective, fog servers are expected to support multitenancy [61], in many cases, service providers may provide the fog nodes in a highly integrated manner in which a single provider manages both the underlying fog servers and the application services. For example, it would be a common case that an indie fog [17]-based UE-fog service provider who follows the common standards to provide the micro-fog services from their own customer premises equipment (CPE) would manage both the fog service software and the host hardware. As another example, Marine Fog systems would deploy the integrated fog nodes on vessels based on the isolated platform for marine activities in order to prevent security issues.

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

There are three types of heterogeneity : server heterogeneity, end-device heterogeneity, and end-to-end 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.

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?