for instance, forwarding sensor data from Medical IoT devices [5].
Near-field communication (NFC) radio-frequency identification (RFID)-based technology, such as NFC may add an additional layer of physical security due to the extremely low signal range, for instance in UE-based Mobile-to-Mobile computation off-loading [55].
1.4.4 LPWAN, Other Medium- and Long-Range Technologies
VHF marine radio VHF is the internationally used technology for marine radio in the frequency range 156—163 MHz. Typical range of VHF is reported to be up to 70 nautical miles from a land-based station [56], while ship-to-ship signal range is below 40 km [57]. However, VHF is limited in supported data rate, which is below 30 kbps. While VHF may be sufficient to transmit sensory readings from ships to shore-deployed fog nodes [4] for aggregation and forwarding, the low data rate is unsuitable for agile transfer of larger data (e.g. video streams or VM images).
Satellite systems offer higher speeds compared to VHF and provide the greatest signal coverage, which is an important factor considering the distances involved in the marine domain. Yet, due to their high cost, these are a viable option only for larger vessels [57, 58].
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].
1.5 Nonfunctional Requirements
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.5 summarizes 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.6 illustrates 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.
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
