Читать книгу Fog Computing - Группа авторов - Страница 31

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.