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

The Internet of Things (IoT) paradigm motivates various next-generation applications in the domains of smart home, smart city, smart agriculture, smart manufacturing, smart mobility, and so forth [1], where the online systems are capable of managing physical objects, such as home appliances, public facilities, farming equipment or production line machines via the Internet. Moreover, mobile objects, such as land vehicles (e.g. cars, trucks, buses, etc.), maritime transports (e.g. ships, boats, vessels, etc.), unmanned aerial vehicles (UAVs; e.g. drones), and user equipment (UE; e.g. smartphones, tablets, mobile Internet terminals, etc.), have become the indispensable elements in IoT to assist a broad range of mobile IoT applications.

Mobile IoT applications emphasize the connectivity and the interoperability among the IoT infrastructure and the mobile objects. For example, in an Internet of Vehicles (IoVs) application [2], the IoT-based smart traffic infrastructure provides the connected roadside units (RSUs) that assist the smart cars to exchange the current traffic situation of the city center toward reducing the chance of traffic accidents and issues. As another example, classic disaster recovery activities of a city require numerous manned operations to monitor the disaster conditions, which involve high risk for human workers. Conversely, by integrating an Internet of Drones (IoD) [3], the smart city government can dispatch a number of drones to monitor and to execute the tasks without sending human workers to the frontline. Unexceptionally, mobile IoT also has benefited maritime activities in terms of improving the information exchange among the vessels and the central maritime management system, hastening the overall process speed of fishery or marine scientific activities [4].

Besides the public applications, mobile IoT plays an important role in personal applications, such as Internet of Medical Things (IoMT) applications [5], which utilize both inbuilt sensors of the UE (e.g. smartphone) and the UE-connected body sensors attached on the patient to collect health-related data and forward the data to the central system of the hospital via the mobile Internet connection of the UE.

Explicitly, the mobile IoT applications described above are time-critical applications that require rapid responses. However, the classic IoT system architecture, which relies on the distant central management system to perform the decision making, has faced its limitation to achieve the timely response due to latency issues deriving from the dynamic network condition between the front-end IoT devices and the back-end central server. Furthermore, the large number of connected mobile IoT devices have raised the challenges of mobile Big Data [6] that increase the burden of the central server and hence, lead to bottleneck issues. In order to improve the agility and to achieve the goal of ultra-low latency, researchers have introduced fog computing architecture [1].

Fog computing architecture (the fog) distributes the tasks from the distant central management system in the cloud to the intermediate nodes (e.g. routers, switches, hubs, etc.), which contain computational resources, to reduce the latency caused by transmitting messages between the front-end IoT devices and the back-end cloud. Specifically, the fog provides five basic mechanisms: storage, compute, acceleration, networking, and control toward enhancing IoT systems in five subjects: security, cognition, agility, low latency, and efficiency [1]. For example, in IoV application, the central server can migrate the best route determination function from the cloud to the roadside fog nodes to assist the travel of the connected vehicles. As another example, in an outdoor-based IoMT application, the hospital system can distribute the health measurement function and the alarm function to the UE in order to perform timely determination of the patient's health condition and to perform an alarm to catch the proximal passengers' attention when the patient is having an incident.

Here, we use the term mobile fog computing (MFC) to describe the fog-assisted mobile IoT applications.

MFC brings numerous advantages to mobile IoT in terms of rapidness, ultra-low latency, substitutability and sustainability, efficiency, and self-awareness. However, the dynamic nature of MFC environment raises many challenges in terms of resource and network heterogeneity, the mobility of the participative entities, the cost of operation, and so forth. In general, the static fog computing frameworks designed for applications, such as the smart home or smart factory would not fully address the MFC-specific challenges because they have different perspectives from the involved entities and the topology. For example, a classic fog computing framework, which may involve a thin mobile client-side application for smartphone users, would not consider how to provide a reliable fog service to the high-speed moving vehicles. Moreover, the classic fog computing framework also would not consider how to provide a reliable fog service to vessels at sea where the telecommunication base stations are not available, and the satellite Internet is too expensive.

The goal of this chapter is to provide an introduction and guidance to MFC developments. Specifically, different from the existing works [7, 8] related to MFC, this chapter discusses MFC in four major application domains: land vehicular fog computing (LV-Fog), marine fog computing (Marine Fog), unmanned aerial vehicular fog computing (UAV-Fog), and user equipment-based fog computing (UE-fog).

The rest of the chapter is organized as follows: Section 1.2 clarifies the term MFC. Section 1.3 breaks MFC down into four application domains and describes their characteristics. Section 1.4 enlists the wireless communication technologies used in the mentioned application domains, while Section 1.5 proposes a taxonomy of nonfunctional requirements for MFC. Open research challenges, both domain-oriented and generic, are identified in Section 1.6, and finally, Section 1.7 concludes this chapter.