Abstract
This paper is a comparative study on the performance of the fog-enabled sensor cloud (FSC) and traditional cloud computing and fog computing modes in a smart logistics park. Based on our previous work, we describe the physical sensor virtualization scheme and framework of the proposed FSC, construct the network model, and mathematically describe the parameters of the FSC. To assess the performance of the proposed platform, we take a large logistics enterprise in China as an example and illustrate the network setup of the proposed platform in a real logistics scenario. The experiment proves that the FSC for smart logistics parks has a practical advantage over the traditional cloud computing and fog computing modes in terms of bandwidth consumption and service latency.
1. Introduction
Sensor Cloud (SC) is the combination of the Internet of Things (IoT) and cloud computing [1, 2], which can be widely used in the smart logistics park to promote the sharing of physical (wireless) sensors (PS) and reduce the redundant deployment of PS too [3]. SC is built on top of PSs and composed of virtual sensors (VSs) which are virtualized from PSs [4]. A virtual sensor is, by definition, a class of computer programme that, given the information at hand, performs the functions that a physical sensor would ordinarily do. As it takes note of readings from several devices and learns to comprehend the correlations between the various factors. The map between PSs and VSs is one-to-one or many to one [5]. The VS is predefined as a piece of code-named VS template that is stored in the cloud, and the VS instance is created based on the VS template while there is a service request [6, 7]. One VS template can create multiple VS instances according to the number of requests (or end users), and multiple VS instances created from different VS templates can form a virtual sensor group (VSG) [8]. Virtual sensors are a type of software layer that uses a fusion function to combine data from physical (or other virtual) sensors to produce oblique measurements of a process variable or an abstract condition. Different end users can control the same PS (including setting sampling frequency, time window, collecting data, sending instructions, etc.) through their own VS instance without interference with each other based on the autonomous coordinate mechanism of SC, so the same PS resources can be shared among multiple users or applications [9].
Fog computing has attracted the attention of researchers since it was proposed by Cisco and has been used to support real-time applications in the context of IoT [10]. As a type of edge computing, fog computing moves the computing and storage resources closer to the application, such as the edge of the Internet, to reduce the transmission delays and realize real-time responses to time-sensitive applications [11]. Applications that need to be executed quickly in response to external events like frame capture or regularly may be required by time-sensitive applications. Fog devices are generally routers, gateways, access points, or some powerful sensor nodes, so fog computing has limited computing and storage capacity compared with cloud computing and can only support simple applications that require little computing and storage resources [12, 13]. Cloud offers a high latency, whereas fog offers a low latency. A cloud system disintegrates in the absence of an Internet connection. As distinct protocols and standards are used in fog computing, the likelihood of failure is quite low. Fog's dispersed architecture makes it a more secure technology than the Cloud. Fog computing can also be widely used in smart logistics to support time-sensitive applications and distributed intelligence, such as intelligent scheduling of logistics devices, intelligent security of park boundaries, intelligent monitoring of storage environments, and so on [14, 15].
In our previous work, we proposed a fog-enabled sensor cloud platform for smart logistics and discussed the architecture, virtualization schemes, and service modes of the platform [16–21]. Clouds have high latency, while fog has low latency. In the absence of an Internet connection, a cloud system fails. Fog computing employs various protocols and standards, reducing the likelihood of failure. Fog has a distributed architecture, which makes it a safer system than the cloud. Software is used in virtualization to imitate hardware features and build a virtual computer system. This makes it possible for IT companies to operate many virtual systems, as well as various operating systems and applications, on a single server. Scale economies and increased effectiveness are two advantages that follow. The previous work is a preliminary consideration of the application of sensing cloud and fog computing in smart logistics parks, and the feasibility and effectiveness of the platform need to be further verified through experiments. So in this paper, we focus on the assessment of the proposed platform. We construct the network model, characterize the performance metrics mathematically, and perform a comparative study of a traditional cloud-based platform with our proposed platform by setting a study case. The novelty of the paper is to model the paradigm of fog-enabled sensor cloud platforms and perform a comparative study in terms of data fusion and latency with respect to cloud-based platforms. A new paradigm for cloud computing called sensor-cloud employs physical sensors to gather data and send it to a cloud computing infrastructure.
The rest of the paper is organized as follows. Section 2 briefly introduces the architecture of the platform, and we construct the network model for the platform in Section 3. In Section 4, we present performance metrics for the platform. Section 5 and Section 6 are the experimental setups for the case study and the performance evaluation of the platform compared with the cloud computing and fog computing-based platforms. Fog computing is a dispersed, decentralised infrastructure, whereas cloud computing is a centralised system. This is the major distinction between the two types of computing. Between computer hardware and a distant server, fog acts as an intermediate. It decides what data should be handled locally and what should be forwarded to the server. Finally, the work is concluded in Section 7.
2. Overview of the Proposed Platform
2.1. Sensor Virtualization
As shown in Figure 1, in the proposed platform, a multilayer physical sensor virtualization solution is applied to realize the reuse of PSs and data fusion of sensing data.
In the fog layer, PSs are virtualized as service instances (SIs). The SIs bridge the PSs deployed in the physical layer and the VSs located in the cloud layer. For batch and real-time processing, Cloud Data fusion provides prebuilt transforms. It allows users to build an external library of unique connections and changes that can be verified, distributed, and used again by different teams. The SIs receive the sensing data collected by PSs and preprocess the data according to preset data fusion policies that are listed in Table 1. The s and p represent the SI and PS, respectively. The b is a bundle of PSs, and an individual PS is considered a special bundle. The h is the aggregator function and the f is the qualifier fusion. An energy-efficient method in WSNs is data aggregation. Sensor networks with a high node density experience redundancy because the same data is perceived by several nodes. Details are shown in our previous work. After the sensing data is preprocessed, the result is either temporarily stored in the fog or forwarded to the cloud (VS) according to the application requirements. In some cases, the SIs can also provide services to local users to reduce the consumption of bandwidth and the response time of requests.
In the cloud layer, the PSs are virtualized as VSs, which receive data forwarded by SIs and provide services to end users. In order to reduce the consumption of the IT resources of the platform, the PSs are temporarily created to respond to the requests of the end-user and will be disposed of once the service is finished. One SI can map to multiple VSs, and multiple VSs can be grouped as one VSG based on specific application scenarios and service requests.
2.2. Framework of the Proposed Platform
As shown in Figure 2, the proposed platform is divided into three PS layer, fog layer, and cloud layer from bottom to top.
The PS layer is composed of PSs, which are deployed in smart logistics parks to collect context information about logistics operations, such as temperature and humidity sensors for warehouse environment monitoring, flame sensors for fire detection, infrared sensors for human intrusion detection, and so on. A thermo-hygrometer is a tool that measures both humidity and temperature in one convenient tool. Your gas heating system's flame sensor is an essential safety feature. A shock or a surface temperature ignitor will really ignite the gas in your gas furnace during the ignition cycle. PSs are generally wireless sensors, and some PSs are mobile, such as sensors embedded in forklifts. An electronic device known as a forklift detection sensor is used to detect or sense the presence of people or objects in the path of a moving vehicle to boost forklift operating safety. PSs form on-field wireless sensor networks (WSNs) in the form of an AD-hoc network, and the number of WSNs in one logistics park is decided by the requirements of logistics management. Ad hoc networks are multi-hop networks made up of wireless independent hosts, where each host might function as a router to help with traffic from other nodes. Each WSN accesses the fog instance through an access point (AP). An AP is a LAN subdevice that gives devices other points of connection, allowing for the addition of more devices without affecting network performance. A large number of wireless sensors are placed in an ad hoc way to create a wireless sensor network (WSN), which lacks any physical infrastructure and is used to track system, physical, and environmental factors.
The fog layer is composed of fog instances, and each fog instance includes multiple fog nodes, which have limited capabilities for computing and data storage. Fog nodes are intelligent intermediate devices and can generally be gateways, routers, switches or special fog devices. In our proposed platform, fog nodes are used to preprocess sensing data to achieve data fusion, to reduce the consumption of network bandwidth, and to deploy some simple applications or some functions of these applications in the fog nodes to reduce the network transmission delay.
The cloud layer is the place where sensor cloud infrastructure (SCI) is located. A brand-new approach to cloud computing called Sensor Cloud transmits all sensor information into a cloud technology architecture using physical sensors to gather data. Numerous monitoring applications employ sensor data, which Sensor Cloud effectively manages. The primary components of SCI are data centers (DCs), portal servers, management servers, provisioning servers, monitoring servers, and virtual servers. To store, process, and distribute data and applications, an organization's common IT operations and hardware are centralised in a data centre. Data centers are essential to the continuity of everyday operations since they store the most important and proprietary assets of a business. DCs are used for the permanent storage of preprocessed sensing data. Portal servers are the interfaces through which users log into the platform. Virtual servers provide companies with an innovative, cloud-oriented service for the future, while servers represent the tried and powerful data centre deployments of the past. The choice is not simple but, at the same time. The main functions of management servers are to manage VSs, fog nodes, and IT resources of SCI, while provisioning servers mainly provide VSs to end users. Virtual servers provide the base running environment for the VS and VSG, while monitoring servers monitor the status of VSs, VSGs, and virtual servers.
3. Network Model of the Proposed Platform
3.1. Definition of Components
As shown in Table 2, the set of PSs is denoted by P = {pi|i ∈ N, |P| = N}, where pi is the ith PS and N is the total number of PSs. PSs are divided into multiple bundles based on the requirements of application scenarios which are denoted by bi, and the set of bundles is denoted by B = {bi}, such that . The set of SIs is denoted by S = {si|i ∈ |B|, si = F (bi), |S| = |B|} and si is the virtualization of bi in the fog layer according to the policies listed in Table 1. The sets of VSs, APs, fog gateways, and cloud gateways are denoted by correspondingly, where i, i, i and i denote the ith VS, AP, fog gateway, and cloud gateway, respectively.
3.2. Modeling the Network
This paper focuses on evaluating the performance of the proposed platform in terms of service latency and bandwidth consumption compared to traditional cloud computing and fog computing paradigm, and the key links are between APs and cloud gateways, so it is assumed that the data transmission bandwidth within the on-field WSN and SCI are unrestricted, while those of the key links are restricted. An excessive amount of bandwidth use can harm a network in many ways, including sluggish upload and downloading speeds and poor site performance.
The data collected by all PSs deployed in the on-field WSNs is transported to the fog layer through the (p, a, s) link, a ∈ A and s ∈ S. pi ∈ b, the pi has the common destination si and is one of the input values of the data fusion function F, so bi ∈ B, the bi is treated as a whole and the transmission route is bi ⟶ a ⟶ si, a ∈ A and si ∈ S. For local real-time applications, the preprocessed result of the data is temporarily stored in fog nodes and directly provided to the application. Otherwise, the result is forwarded to the cloud layer through the (s, , c, ) link, s ∈ S, ∈ , c ∈ C, and ∈ .
The data collected by bi in time-slot t is defined as , in bytes, and is the amount of the data from bi that needs to be redirected to the cloud in time-slot t, in bytes too. We have:where is the data fusion coefficient determined by the fusion function F, and . For the local real time application, the preprocessed result will not be forwarded to the cloud, so . Otherwise, the result will be forwarded to the cloud, so . bi ∈ B, the data fusion function F is fixed on the basis of a predefined data fusion policy, so is fixed too for definite bi. According to detailed data fusing policies, formula (1) can be refined as follows:Where n is an integer and is the number of arguments in the output value of F. is the probability of a particular event occurring while the qualifier function f returns true, and .
The routing variables of the fog layer (FLRV) and cloud layer (CLRV) are defined as , , respectively, i ∈ , ∈ , i ∈ , ∈ , ∈ , ∈ . The FLRV means the route through which the data collected by i in time-slot t reaches the SI i and the CLRV means the route through which the data from i to the destination in time-slot t. Distributed fog computing units, known as fog nodes, which are made up of one or more physical objects with processor and sensing capabilities, enable the deployment of fog services. The Border Gateway Protocol is used by cloud routing to handle links between different virtual cloud networks or between cloud networks and an on-premises network dynamically (BGP). Routing in the cloud adjusts itself automatically to shifting network circumstances. For any given route, the corresponding FLRV and CLRV values are the proportion of the total data sent from the starting point in time-slot t which transmits through the route, so we can get:where invalid means there is no data transmitted through the given route and . If the data is successfully transferred from the starting point to the destination without any loss, we can also get and . The set of all FLRVs in time-slot t is defined as formula (5) and that of all CLRVs is defined as formula (6).
4. Performance Metrics of the Network Model
4.1. Bandwidth Consumption
In the proposed platform, the data fusion is accomplished in the fog layer, so the data transmission is divided into two phases. In the first phase, which is from on-field WSN to the fog instance, the proposed platform has the same bandwidth consumption compared with traditional cloud computing and fog computing modes. The main difference lies in the second phase, that is, from the fog instance to the cloud platform, so in this section, we focus on the bandwidth consumption reduction of the proposed platform in the second phase, and mathematically describe the expression of the same.
The total amount of data traveling through the (b, a, s) link can be expressed as follows:and the total amount of data traveling through the (s, , c, ) link is:
In the traditional cloud mode, all the data collected by bi ∈ B is directly sent to the cloud platform without data fusion, Cloud Data Fusion is a corporate data integration solution for developing and maintaining data pipelines rapidly that is completely managed and cloud-native, so the total amount of the data is expressed as follows:where denotes the total amount of data sent to the cloud in the traditional cloud mode. Based on formulas (8) and (9), we can get the reduction () of the proposed platform compared with the cloud mode:
In the traditional fog mode, all the data collected by bi ∈ B is directly sent to the fog layer at first, and then will be redirected to the cloud except for the data requested by the local real time applications. Different to the proposed platform, there is no data fusion in the process of data transmission, so the total amount of data redirected to the cloud is:where denotes the total amount of the data redirected to the cloud in the traditional fog mode. From formulas (8) and (11), we can get the reduction () of the proposed platform compared with the fog mode:
4.2. Service Latency
In this paper, the service latency is the response time of the request sent by the terminal node within or near the on-field WSN and is divided into the transmission latency and the processing latency. It takes time for a router to process a packet header. A packet’s time in the routing queues is often known as the queuing delay. A packet’s bits must be pushed onto the connection, which adds to the transmission latency. A signal’s propagation delay is the amount of time it takes for it to go across a medium. As mentioned in Section 3, the bandwidth within the on-field WSN and the cloud is assumed to be unlimited, so we focus on the link between the on-field WSN and the cloud, that is, the link (b, a, s, , c, ), b ∈ B, a ∈ A, s ∈ S, , c ∈ C, ∈ .
4.3. Transmission Latency
Similar to the previous part, the link (b, a, s, , c, ) is divided into the link (b, a, s) and the link (s, , c, ), and , are defined as the time delay constant for unit byte data respectively, so in time-slot t, the corresponding transmission latencies (, ) are expressed as:
The mean transmission latency in time-slot t () can be computed as:
Similarly, in the traditional fog computing mode, the mean transmission latency in time-slot t () is expressed as:
In the traditional cloud computing mode, the mean transmission latency in time-slot t () is expressed as:where is time delay constant for unit byte data transmission from an on-field WSN to the cloud platform, and .
4.4. Processing Latency
Let and are the processing delays per byte in the fog layer and cloud layer, respectively, and it is clear that for the limited computing and storage power of the fog nodes. In the proposed platform, the total amount of time spent on data processing () in the fog layer can be computed as follows:and that of the cloud layer () is:so the mean processing delay of the proposed platform is expressed as:
Similarly, in the traditional fog computing mode, the mean processing latency () can be computed as:and that of the traditional cloud computing mode is:
5. Case Study: Simulation Setup
In this section, we take a large logistics enterprise in China as an example and illustrate the network setup for the proposed platform in the real logistics scenario.
5.1. Network Topology
As shown in Figure 3, the logistics enterprise has seven regional distribution centers (RDCs) and 34 logistics parks distributed mainly in southeast China. A regional distribution centre (RDC) is a facility that gathers and consolidates completed goods, parts, and accessories made by its own group of businesses for its own brand for distribution to dealers, importers, subsidiaries, or other unrelated businesses domestically or abroad. The RDC is also the data center (DC) of the region where the SCI is deployed and corresponds to the cloud layer of the proposed platform. The logistics park is where the fog instances are located, to realize data fusion and respond to local real-time applications.
There are 75 refrigerated warehouses for food, 4 refrigerated warehouses for medicine, and 91 e-commerce warehouses located in the 34 logistics parks. Each warehouse includes several on-field WSNs, and each on-field WSN is divided into multiple bundles of PSs according to the requirements of the logistics applications. The free software ensure that all of your warehouse and logistics requirements are met. This tool makes it simple to maintain tabs on deliveries, drivers, and customers. This is the instrument to link all your distribution network connections whenever you need help with your operations.
5.2. Network Traffic
The data traffic of the logistics park is proportional to the number of PSs deployed in the park. Data from the on-field WSNs is transmitted to the fog layer in packets. Considering the energy efficiency of WSNs, the sizes of the packets are set to be between 8 bytes and 200 bytes. Packet arrival is considered to follow a Poisson distribution, with the mean packet arrival rate being 1 packet per second. Discrete probability distributions include those in the Poisson distribution. It provides the likelihood that an event will occur k times within a predetermined period of time or space. As mentioned before, the bandwidth within on-field WSN and the cloud is assumed to be unlimited, but that between the on-field WSN and the cloud ((b, ) link, b ∈ B, ∈ ) is limited. The communication between the WSN and the fog instance ((b, s) link, b ∈ B, s ∈ S) relies on the Intranet of the logistics park with a bandwidth of 1 Gbps, while the communication between the fog instance and the DC ((s, ) link, s ∈ S, ∈ ) relies on the national backbone network of China with a bandwidth of 10 Gbps.
5.3. Physical Sensors
The total number of PSs deployed in the logistics parks is about 100,000. In the process of logistics operation, only active PSs collect the data of logistics, and the active PSs are proportional to real-time logistics traffic, and the number of active PSs changes over time, enabling the assessment of the proposed platform performance in varied network conditions. In this paper, the proportion of active PSs is set in the range [0.65, 0.95] based on the business statistics of the enterprise, as shown in Table 3. Additionally, the proportion of local real-time applications changes dynamically too, with a range of 0.05–0.35.
All the PSs are divided into about 40,000 bundles, the ratios of each type of bundle and the typical PS counts within each type of bundle are shown in Table 4. The number of bundles in each of the 34 logistics parks is proportional to the inventory capacity of the logistics park.
6. Case Study: Performance Evaluation
In details of the results obtained in terms of the performance metrics are presented and analyzed in this section. The simulation setup is mentioned in detail in Section 5. Additionally, we compare the performance of the proposed platform with that of the traditional fog computing and cloud computing architectures and present a thorough study against the same.
6.1. Bandwidth Consumption
Bandwidth consumption is affected by the number of PSs, sensor activation rate, and real-time application ratio, which is represented by ω, in the range of [5, 35]. As shown in Figures 4 and 5, bandwidth consumption is proportional to the number of active status sensors.
Figure 4 shows a comparison between the cloud computing mode and FSC bandwidth consumption. As shown in Figure 4, compared with the traditional cloud computing mode, the proposed FSC for a smart logistics park has good data fusion performance. Meanwhile, as the proportion of real-time applications increases, the bandwidth consumption of FSC gradually decreases.
6.2. Service Latency
Service latency consists of transmission latency and processing latency, so in this part, we compare the sensing delay and processing delay first, and then comprehensively compare the service delay. As in the previous part, this part takes ω to be 0, 5, 10, 20, and 35, respectively. A customer order and a cloud storage provider’s answer are separated by a period of time called cloud service latency. Device use and enjoyment are significantly impacted by latency. For communications using cloud services, which might be particularly susceptible to delays for various reasons, these issues may be exacerbated. The time elapsed between a client’s needs and the cloud service provider’s answer is known as cloud service latency. How useful and pleasurable gadgets and communications are is significantly impacted by latency. These issues may be made worse by cloud storage communications, which may be particularly susceptible to delays for various reasons.
As shown in Figure 6, the FSC has some advantages over the traditional cloud computing model, but it is not obvious. When the proportion of local real-time applications increases, the average network transmission delay decreases slightly.
As shown in Figure 7, compared with the traditional fog computing mode, FSC has a certain advantage in the mean network transmission latency, but it is not very obvious. When the proportion of local applications increases, the mean transmission delay decreases slightly.
As shown in Figures 8 and 9, compared with the traditional cloud computing and fog computing modes, FSC reduces the mean processing latency. As the number of local real-time applications increases, the mean processing latency decreases. When the mean transmission latency and processing latency are combined, the mean service latency shows similar characteristics, as shown in Figures 10 and 11.
7. Summary and Conclusion
The assessment of the FSC proposed in our previous work is a key issue and stage in the research of the combination of sensor cloud and smart logistics park. In this paper, we construct a network model for the FSC for a smart logistics park and evaluate parts of its performance. The experiment proves that the FSC for smart logistics parks has a practical advantage over the traditional cloud computing and fog computing modes. The proposed FSC’s physical sensor virtualization framework builds the network model and calculates the FSC’s parameters. Using a big logistics company in China as an example, we demonstrate the network configuration for the suggested platform in a real-world logistics scenario to evaluate the performance of the platform.
In the future, we will expand the range of performance indicators, such as energy consumption, construction and operating costs, carbon emissions, etc. Meanwhile, based on the model proposed in this paper, sensor virtualization, data fusion, and intra-domain task scheduling in the FSC will be further studied.
Data Availability
The figures and tables used to support the findings of this study are included in the article.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This project is supported by the Natural Science Foundation of Hubei Province (project no. 2019CFC930) and China Society of Logistics (project no. 2020CSLKT3-213).