Internet of Things (IoT) promotes the effective integration of the real world and the digital world by allowing objects of everyday life to be connected everywhere at anytime, to interact with each other, and to exchange data and knowledge [1
]. Thanks to this paradigm, the environments where we live, work, and play will turn into smart user-friendly ecosystems, where billions of heterogeneous devices, including monitoring sensors, actuators, home appliances, vehicles, and smartphones, are seamlessly integrated [2
Smart home, smart building, smart transportation, and smart energy are just a few examples of IoT application domains. In these contexts, the cloud and fog computing paradigms will play a crucial role in supporting the variety of expected services (e.g., data aggregation, filtering, manipulation for monitoring, and surveillance purposes) and in fulfilling their requirements in the presence of a huge number of heterogeneous connected devices. According to References [3
], fog and cloud computing will complement each other to form a service continuum between the cloud and the IoT devices by providing computing, storage, control, and networking resources.
On the one side, by leveraging remote data centers and centralized control, the cloud becomes the perfect candidate for managing long-term data storage and for executing complex analytics algorithms. On the other side, the fog brings computing and storage services close to the end-users, where data are generated and/or consumed. The advantages are clear: enabling interactive and delay-sensitive applications, reducing the amount of traffic reaching the core network segment, and guaranteeing high performance also in the presence of limited network bandwidth and intermittent connectivity. In the most ambitious scenario, network edge routers and hosts, ranging from access points, backhaul nodes, and Points of Presence (PoPs) to IoT gateways and user devices like smartphones and tablets, will turn into fog elements that execute services on demand.
An enabler of such revolutionary vision that integrates computing and networking functionalities is Named Data Networking [5
]. Originally conceived as an architecture for the future Internet, NDN connects heterogeneous devices, ranging from IoT sensors to cloud servers, by naming data bits at the network layer instead of using IP addresses. A consequence of this design choice is that NDN can also name computation services [6
] and implement in-network caching. As a result, clients (the so-called consumers) can request a service by name and the network can find an in-network service executor or even a cached result if the same service has already been computed. By doing so, NDN decouples the service from the identity of the node able to execute it, turning the network edge into a provider-agnostic in-network computing framework.
A few works have been already published that extend NDN to support in-network processing [6
], and the interest in this research field is steadily growing. Although existing approaches differ in the implementation details, their basic idea is to let potentially any NDN node download and execute a named processing function
, i.e., a software that takes as input a content, processes it, and returns a result. Contents can be already available in the network or generated on demand by servers, by IoT sources, or by the clients themselves. According to the consumers’ demands and the nodes’ capabilities, functions can be dynamically migrated in the network or removed if they are not required. Of course, a major challenge in this scenario is the design of effective orchestration mechanisms for allocating the services in the best available nodes.
Different decision criteria can be explored in this context. For instance, an intuitive mechanism could be to execute the service as close as possible to the place where data are produced in order to reduce the data retrieval latency [6
]. Another option could be to execute the service in the less-loaded node in order to reduce the processing latency [9
]. An alternative strategy could be to select the executor according to the service requirements [7
], e.g., compute-intensive services could be deployed in more powerful nodes. With the decisions taken in a distributed way by nodes with limited and time-varying capabilities, implementing even the simplest decision criterion is not trivial; thus, the impact on the final performance could be huge.
In this paper, we explore the NDN fog computing paradigm in a smart environment scenario, with a special focus on the deployment of service orchestration routines. We consider an edge network domain deployed in a smart campus, where a set of NDN IoT devices are installed that produces environmental data, e.g., temperature, humidity, and luminance values from various sensors, and images and videos taken from cameras. NDN fog nodes can retrieve and process IoT data according to the requests they receive from consumers.
In this context, the main original contributions of this work can be summarized as follows:
We extend the NDN architecture to support service provisioning in the campus network and propose a new forwarding strategy that supports the decision of whether the IoT data processing has to be performed into fog nodes or remotely in the cloud in a fully distributed manner. Hence, the strategy is aligned with the fog computing concept.
We conceive a service executor strategy, leveraging a bidding procedure that aims at minimizing the overall service provisioning time, accounting for the retrieval of input IoT data to be processed and for the execution of this processing.
We implement the devised strategy in ndnSIM [11
] and compare its performance through valuable metrics against a set of benchmark orchestration mechanisms available in the literature. The evaluation shows that our proposal outperforms the alternative benchmarking schemes by better scaling as the number of service requests increases. The achieved improvements come at the expense of a slightly higher amount of traffic exchanged among fog nodes.
The rest of the paper is organized as follows. Section 2
provides an overview of the NDN paradigm, notably its suitability for IoT content retrieval in smart environments. The potential of NDN as a key enabler of fog computing is discussed in Section 3
, whereas the relevant literature is discussed in Section 4
. The proposed framework is presented in Section 5
and evaluated in Section 6
. Finally, conclusions are presented in Section 7
5. IoT Service Provisioning via NDN in the Smart Campus
5.1. Reference Scenario and Service Naming
Our reference scenario is shown in Figure 2
, which depicts four distinct 4-floor buildings composing a university campus. This is a smart environment where multiple NDN IoT devices are installed that sense and monitor the environment and produce a variety of data. They can range from simple environmental data, such as temperature, humidity, movements, and luminance values, to larger and complex information, such as video or audio files captured by cameras in specific areas of the buildings.
Without loss of generality, in the following, we define as IoT service an operation that takes as input the raw data generated by the NDN IoT devices and processes them according to a certain computing function. The output of the computation is generally referred to as service result. It can be composed of a single data packet, e.g., a float value indicating the average temperature in a room or a boolean value indicating if there are movements in an area, or multiple data packets, e.g., a compressed video or a dataset indicating the average, maximum, and minimum humidity values in a room.
Generally, there are no restrictions in the way a function must be implemented. According to the literature, functions are generic software programs that can be in the form of unikernel, as in Reference [8
], or containers, as in Reference [42
], or even
-expressions. In the following, we assume that a function is a self-consistent code, identified by a unique name and with a well-defined list of optional input parameters, which can be specified by the consumer; otherwise, a default value will be used.
For instance, a simple function computing the average over a set of float values is named avgF and takes as input a number of s float samples over which the average is computed. If not specified, the default value is considered. Instead, a function compressing flac audio files into mp3 files is named flacToMp3 and takes as input the kilobits per second value, which identifies the quality of the compression (128 kbps, 192 kbps, and 320 kbps). If not specified, the value 128 kbps is considered.
The IoT service is uniquely named in a hierarchical structure with a name composed of three distinct parts: the content name, the function name, and the input parameters. While the first two components are mandatory, the last one is optional. The tag exec
is used for separating the content and the function names. For instance, the name
identifies a service that computes the average value over 5 temperature measurements collected from sensors installed in classroom A, located on the fourth floor of building 1 of the campus.
Consumers, located in the campus as well request IoT services by sending interest packets that carry the service name. Of course, consumers can also request raw (non-processed) contents by sending interests that carry only the traditional content name component, i.e., without the exec tag. To distinguish the two cases, in the following, we refer to as service interest the packet requesting a named service. Vice versa, we call interest a standard NDN packet requesting a content.
According to the standard ISO/IEC 11801 [48
], a wired network is deployed in the campus that connects the IoT devices with a set of infrastructure elements acting as NDN content routers and fog nodes, which in the following is referred to as NDN-fog nodes. In addition to the traditional routing and forwarding operations, they are provided with storage and processing capabilities to dynamically offer IoT services. Of course, their resources are limited with respect to the cloud. As shown in Figure 2
, the network resembles a fat tree topology, with 4 layers and 69 nodes. The root node connects the edge domain to the core network, which in turn is connected to a remote cloud facility.
Services can be executed inside the campus network, if there are available resources, or remotely in the cloud.
5.2. NDN-Fog Node Design
As shown in Figure 3
, NDN-fog nodes implement the legacy NDN data plane, while the control plane is extended with a Service Decision Engine (SDE) that coordinates the following functionalities:
NDN-fog nodes can dynamically download the function code from the so-called Function Data Base, a storage unit located in the campus domain that contains the function catalog. A default route is installed in the FIBs of the NDN-fog nodes towards the Function Data Base; thus, functions can be retrieved by name with the standard NDN interest/data exchange. Of course, if the function code is available in the CS of an on-path node, the latter can directly satisfy the request without further forwarding it.
5.3. Service Provisioning
Service provisioning is performed on demand when service interest packets are sent by consumer applications. The latter are hosted in end-devices (e.g., users’ smartphones or laptops, monitoring utilities, etc.) connected to the leaf nodes of the campus network. When receiving the request, each NDN-fog node applies a processing routine to discover if the result is already cached locally or if itself can be a candidate service executor. The service interest processing includes a bidding procedure that aims at executing the service at the edge in the best available NDN-fog node, which is the one offering the lowest service provisioning time. The latter is computed as the sum of the estimated processing time and the IoT data collection time.
The processing time is estimated according to the currently available node’s resources, as provided by a standard CPU monitoring utility available in the node, once the CPU requirements of the service are known. The IoT data collection is estimated by reading the routing cost from the FIB entry per the requested content name.
The estimated service processing time is included in a new header field of the service interest that we call SPT. The consumer sets the SPT field in the interest to an upper bound value, which represents the time of executing the service in the remote cloud. The parameter is overwritten by an NDN-fog node offering a shorter delay.
If no cached result is located at the edge and no NDN-fog node is available to satisfy the request, e.g., because there are not enough computing resources, then the interest is forwarded to the cloud. As a result, two different forwarding steps are foreseen.
First, the service interest is forwarded in the campus network towards the IoT producer and the discovery is performed by on-path NDN-fog nodes. If the on-path search fails, then the second step starts and the service interest is forwarded towards the cloud. During this stage, newly traversed NDN-fog nodes still attempt to resolve the request locally. If no cached result or executor are located, finally the root node will forward the request to the cloud.
5.3.1. On-Path Forwarding
In this first stage, the service interest is forwarded from the leaf node connected to the consumer, which in the following is referred to as Consumer Access Node (CAN), and to the leaf node connected to the IoT data producer, which in the following is referred to as Producer Access Node (PAN). In case the consumer and producer have the same access node (CAN = PAN), then the candidate on-path executor is just this single node.
Forwarding is guided by the first component of the hierarchical service name, that is, the content name. Specifically, when the CAN or a subsequent NDN-fog node (let us call it ) receives the service interest, the following processing is performed.
First, looks in the CS for a matching name. If it is found, it means that the same service has been previously computed and the result can be immediately sent back to the consumer.
If the CS matching fails, it looks in the PIT. If a matching is found, it means that the same service has been requested and it is pending. Therefore, updates the correspondent PIT entry with the incoming service interest face and discards the packet.
If the PIT matching fails, then the interest is processed by the SDE, which computes the service provisioning time and decides if can candidate itself for the execution. This choice depends on the available computing resources and the implemented service allocation strategy, as it will be clarified in the following section. If the locally computed service provisioning time is lower or equal than the value already included in the SPT field, then becomes the potential service executor: the SDE updates the SPT field and creates a new PIT entry that includes as additional record the service provisioning time. Then, the packet is forwarded to the next node towards the IoT provider (and, therefore, towards the PAN).
After applying the service interest processing, the PAN acts as follows:
If no on-path node is available for the execution, it sends back a NACK packet advertising that the service has not been allocated.
Otherwise, the node with the lowest service provisioning time is selected as the executor. In particular, if the executor is the PAN itself, then it will take in charge the computation. Otherwise, it sends back a data acknowledgement (ACK) packet carrying the service name and the correspondent SPT. The first node with the correspondent SPT in the PIT will act as the executor.
5.3.2. Forwarding towards the Cloud
This forwarding stage is performed only if the service has not been allocated in the path between CAN and PAN, i.e., the service provisioning time offered by the cloud is shorter than the one offered by on-path NDN-fog nodes.
Specifically, the NACK packet is forwarded hop-by-hop back to the CAN, which starts the forwarding process towards the cloud. It modifies the service interest by adding a well-known prefix, e.g., /cloud, to the existing service name and resends the request. Thanks to the newly added name prefix, the request is now forwarded towards the cloud and, therefore, it will reach the root node. Each NDN-fog node receiving the service interest applies the previously discussed processing and evaluates the service provisioning time.
The procedure continues until the interest reaches the root node, which acts in a way slightly similar to the PAN: (i) if no node is available for the execution, the service interest is finally forwarded towards the cloud; (ii) otherwise, the node with the lowest service provisioning time is selected as the executor and a Data ACK is sent back to notify the decision.
5.4. A Toy Example
In order to better figure out how the proposed forwarding strategy works, let us refer to the toy example reported in Figure 4
Service executed on-path
: A consumer C
transmits a service interest (labeled S-INTEREST in Figure 4
a) to request a named service which is routed towards the data provider, P
. The issued interest conveys the estimated service provisioning time in case the service is executed in the remote cloud. Each crossed node along the path estimates the service provisioning time and replaces the current value of the SPT
field in the forwarded interest only if the time is lower than the one carried in the received interest. The interest is then forwarded until it reaches the PAN. In the example, the PAN is not able to execute the service within the shortest time but a node in the path (the CAN in the figure) is able to execute it. Thus, it transmits an ACK back. Once the ACK packet reaches the node that advertised the lowest SPT
, it becomes the executor. Therefore, it starts the data retrieval from the IoT data producer through legacy NDN interest/data packets. Once data are collected, the executor performs the requested computation and sends the result to the consumer using the same name as the original service interest.
Service executed off-path
: In such a case (Figure 4
b), the NDN-fog nodes of the domain cannot ensure a service provisioning time shorter than the cloud; hence, a NACK is sent back by the on-path nodes. The CAN, then, issues a service interest towards the cloud. All nodes forward the packet by overwriting the SPT
field whenever possible. The root node detects the availability of an executor (
) and sends an ACK back.
is then in charge of retrieving data from the provider P
and of sending the output of the computation to C
6. Performance Evaluation
6.1. Simulation Settings
The behaviour of the conceived NDN-fog nodes in the campus network topology depicted in Figure 2
is evaluated in a realistic way by means of ndnSIMv2.5 [11
], the official discrete-event ns-3-based simulator deployed by the NDN community.
We have modified ndnSIM from its stock installation to implement the features of NDN-fog nodes and the abovementioned allocation strategies.
We consider a catalog of 1000 services, each one requiring a randomly selected amount of CPU resources in the range [25–375] Mcycles. Similarly to Reference [49
], since there are no datasets containing traces of the service workloads in real IoT scenarios, we assume that services are requested according to a Zipf distribution with skewness parameter
set to 0.4 and 0.8. The request arrival rate follows the Poisson distribution.
The following benchmarking schemes are considered:
The following metrics are computed for the purpose of performance comparison:
Service provisioning time is computed as the time since the first interest is transmitted from a consumer to request the service until the output of the service execution is sent back (thus including the computation time at the executor).
Offloading-to-the-cloud percentage is derived as the percentage of times the service is executed in the remote cloud. It only applies to our proposal, labeled as NDN-fog.
Intra-edge exchanged traffic is computed as the overall number of NDN packets exchanged into the domain to request a given service, to select the executor, to retrieve the input data to be processed, and to return the result to the consumer.
Simulation settings are reported in Table 2
, and they hold unless differently stated in the text. Results are averaged over 100 runs and reported with 95% confidence intervals.
6.2. Simulation Results
The first set of results, shown in Figure 5
, report the service provisioning time for the compared schemes under different workload settings in terms of size of the content to be processed (
) and arrival rate of service requests (
), when fixing the Zipf parameter
equal to 0.8.
For the cloud solution, the metric is not affected by the parameter : the cloud can sustain high processing loads compared to the edge nodes. The processing time contribution is negligible compared to the latency incurred in retrieving the input content. In fact, the larger the content size, the higher the service provisioning time.
The LLE strategy, on the contrary, is highly affected by parameter . The considered metric highly increases with . The LLE performance is superior to the one experienced by the cloud solution for small arrival rates. This is especially true for large content size settings. As increases, instead, the service provisioning time gets higher than the one provided by the cloud and approaches 10 s.
The CE strategy behaves quite poorly because nodes get rapidly loaded for larger values of . The metric does not change significantly as the content size increases. This is because the waiting time before the processing, which is inevitably experienced at the nodes close to the producers, is much more significant than the time required to retrieve the input content.
Our proposal outperforms the compared schemes under all the considered settings by scaling better with the size of the content and the arrival rate of service requests. However, due to the limited available processing resources at the edge nodes, its performance approaches the one experienced in the case of the remote cloud for high settings.
The better performance of the proposal has to be ascribed to the possibility to select as candidate executors also nodes that are off-path, i.e., in the path towards the cloud (and not only in the one towards the data producers) and the remote cloud itself, as the ultimate solution. This is confirmed by results in Figure 6
. Notably, only a small percentage of services are offloaded to the cloud and only when the parameter
is large. The larger the content size, the lower the offloading-to-the-cloud percentage. This is because the latency contribution due to content retrieval by IoT producers gets more significant for the cloud.
The supremacy of NDN-fog compared to the benchmark schemes is paid in terms of a larger amount of traffic generated in the domain, as shown in Table 3
. For small content size settings, the intra-edge exchanged traffic for NDN-fog approaches values experienced by the cloud solution. As the content size increases, the intra-edge exchanged traffic in NDN-fog gets smaller compared to the cloud, although it is still higher than the CE solution, performing the execution as close as possible to the data producers.
It is interesting to observe that improvements of the proposed solution compared to the considered benchmark schemes are still significant under less favourable settings in terms of service popularity, i.e.,
. The service provisioning time increases since more distinct services need to be executed, wasting processing resources of nodes. For NDN-fog, the metric achieves values are well below the ones provided by the benchmark schemes (see Figure 7
The larger processing load at NDN-fog nodes results in a larger percentage of services offloaded to the cloud compared to the previous case with
; see Figure 8
. The impact of different round-trip-time (RTT) values towards the cloud on the metric is also evaluated. The larger the RTT, the lower the metric: it is more convenient to execute the service at the edge to reduce the service provisioning time. This is especially true as the input content size increases.
For what concerns the intra-edge traffic, the same trends already discussed for
can be observed in Table 3
. However, a higher traffic is exchanged due to the presence of less popular services.
7. Conclusions and Future Work
In this paper, we have discussed the potential of NDN to support fog computing in smart environments. After scanning the relevant literature, our proposal has been presented that is tailored without loss of generality to the representative IoT smart campus scenario. We have proposed a service orchestration mechanism which is fully aligned with the fog computing concept. Indeed, it supports the decision of whether the IoT data processing has to be performed at the edge or remotely in the cloud in a fully distributed manner and targeting the minimization of the service provisioning time.
Achieved simulation results confirm the supremacy of our proposal against literature solutions under different workload settings (i.e., input content size and arrival rate of service requests). Improvements are significant in terms of reduction of the service provisioning time. As a drawback, the proposal incurs a slightly higher amount of traffic exchanged in the edge domain. Such a condition holds when comparing NDN-fog against the conventional cloud solution only for small content sizes. The larger traffic exchanged compared to the CE strategy is widely compensated by the achieved reduction of the service provisioning time, which is well below 10 s for NDN-fog under all the considered settings.
All in all, the proposal adequately targets a user-centric policy which values more how the consumers perceive the services in terms of service provisioning time, in our case, than the incurred traffic in the edge domain.
Future works will be devoted to the design of service executor strategies with different objectives, e.g., targeting computing load balancing and reducting the amount of exchanged traffic while also considering services with different priorities. Moreover, we plan to investigate the integration of the NDN fog computing paradigm with other emerging techniques, such as software-defined networking (SDN) and network function virtualization (NFV).