Keywords

1 Introduction

The proliferation of IoT technology has brought the unprecedented convenience to people and draw widespread attentions from both academia and industry [3]. Currently, cloud plays a major role in providing these highly personalized, context-aware IoT services because of the advantages like cost reductions, easy deployment and strong reliability. However, the new challenges presented by real-time IoT applications like stringent latency and Quality of Service (QoS) requirement are not well addressed by the standalone cloud computing paradigm.

In order to address aforementioned issues and overcome inadequacy of the cloud, fog computing is introduced. The idea of extending cloud to the edge of network and closer to end users has been viewed as an alternative with the overarching goal of “off-loading” from the cloud. Fog nodes, acting as the proxy of both cloud and end devices/users (things), could be equipped with computing, storage and networking resources to accommodate various IoT applications. Therefore, these applications could be deployed in fog rather than the conventional approach on either resource-constrained IoT devices or remote cloud. In this regard, fog and cloud complement each other to form a service continuum that distributes respective services to end users [2].

Along with the rapid growth of IoT applications, heterogeneous services are tailored for service consumers with certain QoS guarantee. In reality, stable service delivery rate is a key component to meet the QoS and it could act as a major part in service consumers perception with regard to overall performance of service invocation [1]. In our work, the utility function is used to model the QoS performance, which increases as the increasing of service delivery rate. From the utility point of view, the services can be categorized into two main groups, i.e., traditional elastic services (e.g., file transfer, data analysis and web browsing), in which each service attains a strictly increasing and concave utility function to measure its QoS performance, and real-time inelastic services provided by audio, video and multimedia real-time applications. Such inelastic services have an intrinsic bandwidth threshold in nature and adopt the sigmoid-like functions to describe the corresponding QoS [5].

There are several previous efforts made towards developing service delivery architecture to connect service consumers and providers in IoT environment. A vehicular data cloud platform is proposed in [4] to provide real-time information, yet concerns like service transmission latency and transportation cost are not discussed. Some service platforms aim to utilize underlying IT resources to achieve good QoS through NUM, e.g, the automatic service routing platform proposed in [1] and the multicast multirate service delivery platform in [8], but their works either are not designed for IoT environment, or fail to support inelastic, real-time IoT services. Given that, the advantages of RA-FSD platform are highlighted as follows: (1) it seamlessly integrates fog computing into IoT environment, and utilizes fog node as service provider equipped with more computation and storage resources than traditional IoT devices; (2) it offers services that are generated in the proximity of users, and both service transportation cost and delivery latency are largely reduced; (3) beside elastic services, it also supports real-time inelastic services.

Fig. 1.
figure 1

Fog computing architecture, and example services provided by cloud and fog nodes

2 Architecture of RA-FSD Platform

In this section, we introduce the architecture of RA-FSD platform and the components inside. The platform is composed of heterogeneous things, fog nodes and the cloud. From the service-oriented computing perspective [7], things normally play the role of service consumers/requesters, fog nodes equipped with computation, storage and networking power could serve as either service providers or service intermediaries, in which service intermediaries help collect service requests from bottom-level things, track network conditions, cooperate with providers to adapt service transmission rate, and forward services back to requesters. Since the cloud treats fog as the proxy in the edge network, it is noticeable that the use of cloud is no longer mandatory under this platform, but one could choose to continue using cloud as service provider for particular services, e.g., advanced analytic service for big data.

Figure 1 presents a simple fog architecture with a multi-level hierarchy, including different types of service provisioned inside. The bottom layer consists of the end devices or users. The fog nodes have been positioned in the middle two layers, and similar to the traditional IoT network, the cloud is at the top layer. Taking advantage of the geographical locations, IoT applications could deploy on the fog nodes in the vicinity of things and fog node is thus able to serve as the real-time service provider in IoT network. In addition, fog node selected as provider would form the corresponding service group in which a particular service could be disseminated. Specifically, the provider in each group will gather feedback regarding downstream network conditions reported by service intermediaries to adjust transmission rate for different service receivers. Service intermediaries, on the other hand, collaborate with providers and could be converted to the providers if needed, which increases the scalability and flexibility of the platform. In general, the cloud is only used as service provider if that service associates with a large volume of data processing and storage, or service requested is delay-tolerant.

3 Analytic Framework and Optimization Problem

The NUM resources allocation problem in the fog-based IoT environment is formulated in this section to make it support both elastic and real-time inelastic services. In addition, we characterize the utility in terms of allocated service transmission rate deriving from the underlying bandwidth of IoT network. Consider a fog service delivery network consisting of a set of links \(L = \{1,2,....,l\}\), each of which has respective capacity \(c_{l}\). There is a set of \( S=\{1,2,....,s\}\) service groups, and each service group is devoted to providing one service. For each service group s, there is only one unique service provider, which is either a fog node or the cloud. A set of receivers in service group s could be defined as \(R_{s} = \{r_{s,1},r_{s,2},....,r_{s,n}\}\), and along with a set of links \(L_{s}\subset L\). They together form the corresponding service delivery tree for that service group, where the provider stays at the root of the tree, and each receiver in \(R_{s}\) is connected to the IoT network through the leaf fog nodes.

For each service receiver \(R_{s,i} \in R_{s}\) in a service group, \(L_{s,i} \subset L_{s}\) describes the service delivery path from the provider of service group s to relevant receiver i. Utility function \(U_{s}(x_{s,i})\) has been selected on per-service basis, which is customized to describe the QoS requirement. In addition, utility function should be strictly increasing and continuously differentiable, but needs not be concave in our work. \(x_{s,i}\) represents the service delivery rate to receiver i in service group s.

We then formulate the following optimization problem, on the basis of multicast, multirate model similar to [8]:

$$\begin{aligned} \begin{aligned}&P1:&\max \limits _{x \ge 0}U(x)=\sum _{s \in S}\sum _{i=1}^{n_{s}}U_{s}(x_{s,i}) \end{aligned} \end{aligned}$$
(1)
$$\begin{aligned} \begin{aligned}&\text {subject to}&\sum _{s \in S} x_{s}^{l} \le c_{l}, \quad \forall l \in L \end{aligned} \end{aligned}$$
(2)
$$\begin{aligned} \begin{aligned}&x_{s}^{l}=\max \limits _{\{i|l \in L_{s,i}\}}x_{s,i} = \lim _{N \rightarrow \infty }\bigg (\sum _{\{i|l \in L_{s,i}\}}x_{s,i}^{N}\bigg )^{\frac{1}{N}} \end{aligned} \end{aligned}$$
(3)

In Eq. (3), \(\{i|l \in L_{s,i}\}\) is a set of receivers that uses link l to receive the corresponding service in service group s. This equation states that in service group s, the service rate on link l is the same as the rate of the fastest downstream receiver in this group. In addition, constraint (2) in this optimization problem means that the aggregate service rate on link l across all service groups should not exceed the link capacity (network condition). Then we replace (3) in (1) and the Lagrangian multiplier could be yielded:

$$\begin{aligned} L(x,p)=\sum _{s \in S}\sum _{i=1}^{n_{s}}U_{s}(x_{s,i})-\sum _{l \in L}p^{l}\Bigg [\sum _{s \in S}\bigg (\sum _{\{i|l \in L_{s,i}\}}x_{s,i}^{N}\bigg )^{\frac{1}{N}}-c_{l}\Bigg ] \end{aligned}$$
(4)

In order to make our platform support both elastic and inelastic services, a pseudo utility function [5] is constructed as (5) to substitute the original optimization problem P1:

$$\begin{aligned} \begin{aligned}&\mathcal {U}_{s}(x_{s,i})=\int _{m_{s}}^{x_{s,i}}\frac{1}{U_{s}(y)}dy, \quad m_{s}\le x_{s,i}\le M_{s} \end{aligned} \end{aligned}$$
(5)

where \(m_{s}\) and \(M_{s}\) represent minimum and maximum service delivery rate, respectively. Based on the characteristic of original utility function \(U_{s,i}(x_{s,i})\), this pseudo utility function must be strictly increasing and concave as \(\mathcal {U}^{\prime \prime }_{s}(x_{s,i}) < 0\). By solving the optimization problem, the derived results could be further incorporated into the service rate-adaptive algorithm.

4 Service Rate-Adaptive Algorithm and Implementation

figure a

The algorithm is devised to take advantage of the architectural support from the platform and is deployed on all fog nodes to periodically check the network conditions as well as adapt the service delivery rates accordingly. By choosing appropriate fog node as service provider, the corresponding service generated could traverse less hops than the cloud scheme and thus make it suitable for delay-sensitive IoT applications.

Algorithm 1 presents a summary of the algorithm, which incorporates the analytic results derived in Sect. 3 and comprises two phases. The service intermediaries would firstly gather relevant downstream links information, then report it upwards recursively to form the fog service continuum (lines 2–3). Afterwards, several service groups have been established, and whenever a service requester joins or leaves a service group (network changes), the bottom-level fog node is able to detect the change and report it upwards, which consequently starts another round of phase 1. In phase 2, fog nodes would firstly iterate through each downstream links and calculate the current link status. More specifically, lines 5–10 deal with the link price updating process, followed by the calculation of price weighting coefficient in lines 11–17, which implies that this coefficient would continue to increase for receiver with the largest service rate, while decreasing among other receivers. Lines 18–27 handle the service rate adjusting process, if and only if current node f is a service provider.

Fig. 2.
figure 2

Fog architecture in the shopping mall use case

5 Performance Evaluation on a Case Study

In this section, we verify the feasibility of proposed platform with the algorithm through a real-world shopping mall use case. Besides, the numerical results are meanwhile used to demonstrate the applicability and robustness of the RA-FSD platform. It is worthwhile mentioning that, as elastic service is relatively easier to be accommodated, our focus on the use case is to implement inelastic services originated from real-time applications.

Figure 2 illustrates the topology of the IoT network empowered by fog architecture in the shopping mall. In this topology, all fog nodes represented as the dot points are placed inside the shopping mall, along with two different sizes of digital displays acting like things. The topmost fog node is configured as the most powerful node among all, and operates as the main gateway of this autonomous network. In addition, cloud is only used for data backup purpose.

The performance of RA-FSD platform is evaluated through simulations. The fog network originally contains 7 links labeled as \(l_{1},l_{2},.....,l_{7}\) with relevant capacities c = (6, 4, 10, 8, 8, 12, 18) (in Mbps), and these links have been shared between two service groups \(s_{1}\), \(s_{2}\). In addition, two types of screens require different services transmission rates to satisfy respective QoS requirement. The utility function \(U_{1}(x_{s=1,i})=\frac{1}{1\,+\,e^{-2(x-6)}}\) is used to reflect the QoS performance of inelastic service 1, and \(U_{2}(x_{s=2,i})=\frac{1}{1\,+\,e^{-2(x-4)}}\) for service 2.

The simulations start at time \(t=0\), and service group 2 contains relatively small screens \(r_{2,1},r_{2,2},r_{2,3}\), while service group 1 only has one big screen \(r_{1,1}\) at the start. The minimum and maximum service delivery rates to each screen are set to be 0 and 10 Mbps but will be adapted quickly based on the feedback of network condition. The platform triggers the algorithm at the bottom-level fog node at every time interval of 0.1 s and experimental results including service rate and utility are expected to reach a stable state rapidly to demonstrate the applicability of the platform. It is also noticeable that at \(t = 60\) s, two new displays \(r_{1,2}\) and \(r_{1,3}\) have joined service group 1 and establish connections to fog nodes through links \(l_{8}\) and \(l_{9}\) (dashed-line links) with capacities of 10 and 8, respectively, while \(r_{2,3}\) has suddenly left service group 2 along with a disconnection of link \(l_{4}\). The abrupt changes of topology is not uncommon in real-world situation, which is hereby used to validate the robustness of the platform.

Fig. 3.
figure 3

The service delivery rates in different service groups

Fig. 4.
figure 4

The utility results in different service groups

The simulation results of service delivery rates (\(x_{s,i}\)) and utility results (QoS) in service groups 1 and 2 are shown in Figs. 3 and 4, respectively. It is clearly observed that all service rates converge to the optimum under the complex IoT network conditions even with the abrupt network changes. The platform is capable of eliminating the instability, and relevant fog service providers can concretely adapt service rate for each receiver to maintain a relatively good QoS. The minimum service delivery rate achieved in this scenario is 4 Mbps and the overall QoS achieved by the platform retains the value of more than 0.5, which substantially suffices the service requirements of displays in the shopping mall use case [6].

To conclude, the simulation results reconfirm that our proposed platform is applicable and robust in real-world scenario, and also capable of handling abrupt network changes. Furthermore, the convergence of service delivery rates and corresponding utilities clearly demonstrate that the platform could support real-time inelastic services offered by the fog service providers.

6 Conclusion and Future Work

In this paper, we have proposed a novel rate-adaptive fog service delivery platform that is applicable for current IoT network. Important issues in traditional service-oriented IoT network such as service transmission latency and huge bandwidth waste have been well addressed by applying RA-FSD. Heterogeneous IoT services now offered in the vicinity of things as fog node could serve as providers that are only a few hops away. Additionally, fog nodes in our platform work collectively to maintain the stability of the IoT network.

Our case study verifies that, on the basis of fog architecture, RA-FSD seamlessly integrates service rate-adaptive algorithm, and copes with real-world scenarios effectively even with the abrupt changes occurred in the IoT network (new joiner or leaver). Moreover, both elastic and inelastic IoT services are well supported in the platform. Our next phase of research will focus on developing the provider “pick up” strategy, in which RA-FSD platform should dynamically select a fog node as the service provider based on its characteristic such as computing power, geographic location or network condition.