HAL Id: hal-02354073https://hal.inria.fr/hal-02354073

Submitted on 7 Nov 2019

HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, estdestinée au dépôt et à la diffusion de documentsscientifiques de niveau recherche, publiés ou non,émanant des établissements d’enseignement et derecherche français ou étrangers, des laboratoirespublics ou privés.

Fog Computing in IoT Smart Environments via NamedData Networking: A Study on Service Orchestration

MechanismsMarica Amadeo, Giuseppe Ruggeri, Claudia Campolo, Antonella Molinaro,

Valeria Loscri, Carlos Tavares Calafate

To cite this version:Marica Amadeo, Giuseppe Ruggeri, Claudia Campolo, Antonella Molinaro, Valeria Loscri, et al.. FogComputing in IoT Smart Environments via Named Data Networking: A Study on Service Orchestra-tion Mechanisms. Future internet, MDPI, 2019, 11 (11), pp.222. �10.3390/fi11110222�. �hal-02354073�

future internet

Article

Fog Computing in IoT Smart Environments viaNamed Data Networking: A Study on ServiceOrchestration Mechanisms

Marica Amadeo 1,∗ , Giuseppe Ruggeri 1 , Claudia Campolo 1 , Antonella Molinaro 1,2 ,Valeria Loscrí 3 and Carlos T. Calafate 4

1 DIIES Department, University Mediterranea of Reggio Calabria, Via Graziella, Loc. Feo di Vito,89100 Reggio Calabria, Italy; giuseppe.ruggeri@unirc.it (G.R.); claudia.campolo@unirc.it (C.C.);antonella.molinaro@unirc.it (A.M.)

2 Laboratoire des Signaux et Systémes (L2S), CentraleSupélec, Université Paris-Saclay,91190 Gif-sur-Yvette, France

3 Inria Lille-Nord Europe/FUN, 59650 Villeneuve D’Ascq, France; valeria.loscri@inria.fr4 Department of Computer Engineering (DISCA), Universitat Politècnica de València, 46022 València, Spain;

calafate@disca.upv.es* Correspondence: marica.amadeo@unirc.it; Tel.:+39-0965-1693276

Received: 24 September 2019; Accepted: 21 October 2019; Published: 24 October 2019�����������������

Abstract: By offering low-latency and context-aware services, fog computing will have a peculiarrole in the deployment of Internet of Things (IoT) applications for smart environments. Unlike theconventional remote cloud, for which consolidated architectures and deployment options exist, manydesign and implementation aspects remain open when considering the latest fog computing paradigm.In this paper, we focus on the problems of dynamically discovering the processing and storageresources distributed among fog nodes and, accordingly, orchestrating them for the provisioningof IoT services for smart environments. In particular, we show how these functionalities can beeffectively supported by the revolutionary Named Data Networking (NDN) paradigm. Originallyconceived to support named content delivery, NDN can be extended to request and provide namedcomputation services, with NDN nodes acting as both content routers and in-network serviceexecutors. To substantiate our analysis, we present an NDN fog computing framework with focuson a smart campus scenario, where the execution of IoT services is dynamically orchestrated andperformed by NDN nodes in a distributed fashion. A simulation campaign in ndnSIM, the referencenetwork simulator of the NDN research community, is also presented to assess the performanceof our proposal against state-of-the-art solutions. Results confirm the superiority of the proposalin terms of service provisioning time, paid at the expenses of a slightly higher amount of trafficexchanged among fog nodes.

Keywords: Internet of Things; named data networking; information centric networking;fog computing; smart environments; service orchestration

1. Introduction

Internet of Things (IoT) promotes the effective integration of the real world and the digital worldby 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 seamlesslyintegrated [2].

Future Internet 2019, 11, 222; doi:10.3390/fi11110222 www.mdpi.com/journal/futureinternet

Future Internet 2019, 11, 222 2 of 21

Smart home, smart building, smart transportation, and smart energy are just a few examples ofIoT application domains. In these contexts, the cloud and fog computing paradigms will play a crucialrole in supporting the variety of expected services (e.g., data aggregation, filtering, manipulation formonitoring, and surveillance purposes) and in fulfilling their requirements in the presence of a hugenumber of heterogeneous connected devices. According to References [3,4], fog and cloud computingwill complement each other to form a service continuum between the cloud and the IoT devices byproviding computing, storage, control, and networking resources.

On the one side, by leveraging remote data centers and centralized control, the cloud becomes theperfect 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 dataare generated and/or consumed. The advantages are clear: enabling interactive and delay-sensitiveapplications, reducing the amount of traffic reaching the core network segment, and guaranteeinghigh performance also in the presence of limited network bandwidth and intermittent connectivity. Inthe most ambitious scenario, network edge routers and hosts, ranging from access points, backhaulnodes, 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 functionalitiesis Named Data Networking [5]. Originally conceived as an architecture for the future Internet, NDNconnects heterogeneous devices, ranging from IoT sensors to cloud servers, by naming data bits atthe network layer instead of using IP addresses. A consequence of this design choice is that NDNcan also name computation services [6,7] and implement in-network caching. As a result, clients (theso-called consumers) can request a service by name and the network can find an in-network serviceexecutor or even a cached result if the same service has already been computed. By doing so, NDNdecouples the service from the identity of the node able to execute it, turning the network edge into aprovider-agnostic in-network computing framework.

A few works have been already published that extend NDN to support in-network processing[6–8], and the interest in this research field is steadily growing. Although existing approaches differin the implementation details, their basic idea is to let potentially any NDN node download andexecute a named processing function, i.e., a software that takes as input a content, processes it, andreturns 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 forallocating the services in the best available nodes.

Different decision criteria can be explored in this context. For instance, an intuitive mechanismcould be to execute the service as close as possible to the place where data are produced in order toreduce the data retrieval latency [6]. Another option could be to execute the service in the less-loadednode in order to reduce the processing latency [9,10]. An alternative strategy could be to select theexecutor according to the service requirements [7,8], e.g., compute-intensive services could be deployedin more powerful nodes. With the decisions taken in a distributed way by nodes with limited andtime-varying capabilities, implementing even the simplest decision criterion is not trivial; thus, theimpact 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 networkdomain deployed in a smart campus, where a set of NDN IoT devices are installed that producesenvironmental data, e.g., temperature, humidity, and luminance values from various sensors, andimages and videos taken from cameras. NDN fog nodes can retrieve and process IoT data according tothe requests they receive from consumers.

Future Internet 2019, 11, 222 3 of 21

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 andpropose a new forwarding strategy that supports the decision of whether the IoT data processinghas 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 minimizingthe overall service provisioning time, accounting for the retrieval of input IoT data to be processedand for the execution of this processing.

• We implement the devised strategy in ndnSIM [11] and compare its performance through valuablemetrics against a set of benchmark orchestration mechanisms available in the literature. Theevaluation shows that our proposal outperforms the alternative benchmarking schemes by betterscaling as the number of service requests increases. The achieved improvements come at theexpense 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 NDNparadigm, notably its suitability for IoT content retrieval in smart environments. The potential of NDNas a key enabler of fog computing is discussed in Section 3, whereas the relevant literature is discussedin Section 4. The proposed framework is presented in Section 5 and evaluated in Section 6. Finally,conclusions are presented in Section 7.

2. Named Data Networking and Its Role in IoT Smart Environments

2.1. NDN in a Nutshell

NDN is an Information Centric Networking (ICN) architecture that turns content into a first-classnetwork citizen [5,12,13]. Unlike the current Internet, where communication is based on namedhosts, in NDN, each content is uniquely named and secured at the network layer. Routing andforwarding operations are directly based on content names, and in-network caching is nativelyenabled. Together with other innovative paradigms, like edge and fog computing, NDN has beenrecognized as a fundamental pillar of the future Internet [14] that can offer highly scalable and efficientcontent dissemination in different network scenarios, ranging from the wired Internet to wireless adhoc environments and IoT systems. Indeed, NDN defines a connectionless communication modelextremely suited to IoT environments.

Basically, NDN communication leverages only two packet types: the Interest, used to requestcontents, and the Data, used to carry the content. Both packets carry a hierarchical name that uniquelyidentifies a piece of data. Names are in the form of Uniform Resource Locators (URLs), and they canbe human-readable and user-friendly. Name prefixes are distributed by the network routing protocolsto enable the reachability of contents.

Three main communication actors can be identified: (i) the consumer, which sends Interests torequest contents; (ii) the original producer, which originates the data packets; and (iii) the content router,which forwards interests and data packets and may cache the latter to satisfy future requests. Datapackets are signed at the time of creation by their producers. This allows to decouple the trust in thedata from the trust in the nodes that may cache them. In the following, producers and cachers ofcontents are both referred to as providers.

Being a networking solution, NDN operates at two levels: the data plane and the control plane, asdetailed in the following subsections.

2.1.1. Data Plane

As shown in Figure 1, each NDN node maintains three tables at the forwarding plane (also knownas, the data plane).

Future Internet 2019, 11, 222 4 of 21

Figure 1. Named Data Networking (NDN) node’s data plane.

The Content Store (CS) is used for caching incoming data packets. Depending on the scenarioand the available storage resources at the node, several decision policies can be implemented, rangingfrom the simple caching-everything-everywhere strategy to the probabilistic caching and the moreadvanced popularity-based autonomous or cooperative mechanisms [15]. The caching policy is alwayscoupled with a replacement strategy that is applied when the storage space is full and a new itemmust be cached. The default replacement policy in NDN is Least Recently Used (LRU).

The Pending Interest Table (PIT) tracks the transmitted interests together with theincoming/outgoing interfaces. This forwarding state is maintained until the data packets consume theinterests, a lifetime expires, or a negative acknowledgement (NACK) is received to advertise an errorthat occurred along the path.

The Forwarding Information Base (FIB) maintains the outgoing interface(s) per named prefix.Multiple interfaces may exist per prefix, ranked by routing preferences. Interfaces are called facesin the NDN context. In particular, two face abstractions are identified: the NetDeviceFace, whichenables communication with the underlying physical networks, and the AppFace, which enablescommunication with the applications.

2.1.2. Forwarding Fabric

Only interests are routed in NDN [16]. Specifically, at the interest reception (from the applicationlayer or from the underlying access network layer), each node runs the following processing:

• First, the node looks in the CS. If a matching is found, the data packet is immediately sent overthe same interface that the interest arrives from.

• Otherwise, the node looks in the PIT. If a match is found, it means that the same request hasalready been forwarded, the node is waiting for the data, and there is no need to transmit it again.As a result, the interest is discarded and the node only updates the PIT entry with the incominginterface of the received interest. Such a feature, typically referred to as request aggregation,reduces the number of accesses to the original content source.

• If also the PIT matching fails, the node looks in the FIB to forward the interest over an outgoinginterface. In case of failure, a NACK can be sent back and the interest is discarded.

Data packets are forwarded over the same interfaces that the interests were received, according tothe PIT entry.

Future Internet 2019, 11, 222 5 of 21

2.1.3. Control Plane

The NDN control plane is in charge of the routing decisions and includes the Routing InformationBase (RIB) and the Strategy Choice Table (SCT). RIB entries are originated by manual configurationfrom administrators, applications, and routing protocols and are used to update the FIB. The SCT,instead, identifies the forwarding strategy per namespace; it can be updated by management protocolsor administrators, and it is supposed to be quite stable. The forwarding strategy is responsible fordeciding if it should, on which face to, and when to forward NDN packets.

2.2. NDN in Smart Environments

The potential of NDN in IoT smart environments has been widely recognized in the literature[17,18]. Indeed, NDN well matches the pattern of many IoT applications that focus on the data itself(e.g., the temperature in a room and the average speed of vehicles in a road segment) rather thanon a specific data producer. The NDN interest/data exchange can be used to support a variety ofmonitoring services by directly using application-level names [19]: requests for monitored parameterscan be carried in interest packets; at the reception of the interest, a provider can send the data back.In-network caching and request aggregation natively reduce the traffic load and the number of accessesto the original producer; this is especially useful when providers are resource-constrained IoT devices.

NDN communication can also support actuation services, e.g., to switch on/off lights [20,21]: inthis case, specific named commands can be carried in the interest packets that are forwarded towardsthe things in charge of executing them. A data packet can be sent back to acknowledge the commandexecution.

According to References [17,19], NDN names for smart environments can be convenientlystructured in three main parts. First, a main prefix should be identified that specifically refers tothe IoT domain, e.g., /unirc. The main prefix can be advertised by the routing protocol and maintainedin the FIBs of network core nodes to allow the reachability of the IoT domain from remote consumers.If the IoT domain is large, e.g., a university campus, other subcomponents of the domain namecan be specified, e.g., /eng/buildingA/telcolab identifies a specific laboratory in a given buildingof a certain faculty. Second, a set of middle components can be defined to identify the IoT data(e.g., /temperature, the thing, or the actuation command (e.g., /light/on). Finally, a last optionalcomponent can identify the specific instance of the data, e.g., /2019031430. Therefore a name like/unirc/eng/buildingA/telcolab/temperature/2019031430 uniquely identifies a temperature valuesensed on 3 March 2019 at 14:40 in the Telco Laboratory of the Engineering Faculty at the University ofReggio Calabria.

Last but not least, NDN communication in smart environments can leverage a strong per-packetauthentication and integrity support involving both interest and data packets. Data packets arealways signed by their original producers, and in the case of sensitive actuation services, the interestpackets can be signed by the consumers to ensure that certain actions are requested only by authorizedauthenticated entities [20]. Public key cryptography is usually the reference mechanism for signingNDN packets [22]. However, mechanisms based on symmetric cryptography are preferred forresource-constrained IoT devices [23].

To ensure data confidentiality and access control when dealing with sensitive IoT services,NDN uses encryption and requires an automated key management system to distribute the sessionencryption and decryption keys to the involved entities [24].

Future Internet 2019, 11, 222 6 of 21

3. NDN: The Networking Paradigm for Fog Computing

3.1. Fog Computing: Key Pillars and Issues

The fog computing paradigm has been initially proposed in the pioneering work ofBonomi et al. [25], was highly promoted by Cisco [26], and was further refined by the industrialand academic communities [4] to enable computing, storage, and networking close to the end-user.

End-user devices or near-user edge devices can be leveraged to carry out communicationand computation in different IoT domains, such as industrial plants [27] and vehicularenvironments [28,29].

Other similar paradigms to fog computing such as edge computing, mist computing, and cloudletshave been proposed by the research community with similar purposes [30]. Despite the similarities interms of targeted objectives, the OpenFog consortium [4], bringing together industry companies andacademic institutions across the world for the sake of standardization and promotion of fog computing,recognizes a more comprehensive scope and flexibility of the fog in that it seeks to enable computingservices anywhere from cloud to things, as data typically moves from the IoT devices to the processingnodes. This is a clear departure from many existing solutions that treat network edges as isolatedcomputing platforms and are not inclusive of the cloud.

Such a kind of deployment particularly challenges service addressing; discovery and provisioning;and management aspects, like orchestration of services and network resources [30,31].

Requests for a computing service (i.e., the execution of a given processing function over a givencontent) are issued regardless of the position (address) of the executor node, of which the identityis not a priori known to the requester. A service may reside on a number of local nodes, or it maypartially reside on local nodes and on the cloud. Conventional addressing schemes are not suited tomatch the service-centric nature of the targeted context.

Discovery procedures are typically performed with the help of an application-layer brokermechanism [32,33] that matches the service request with the best available node that is able to executethe service based on specified requirements and discovered capabilities. These broker entities, however,further complicate the reference scenario.

3.2. NDN as Enabler of Fog Computing

Recently, NDN has been considered an enabler of edge and fog computing because it can supportprovider-agnostic in-network computing and caching services [34,35]. According to this new vision,interest packets can be overhauled to let a consumer request by name not only a content but also aspecific computation service. Such named service requests can be processed directly at the networklayer. Services can be executed by any node in the network that owns the required capabilities.The named service can process contents already available in-network (i.e., in the CS of a router) orproduced on demand by another source or even produced by the consumer itself. Data packets can beoverhauled to carry computation results that can be stored in the CS of NDN nodes to satisfy futurerequests. This is a radical departure from IP-based fog computing approaches, which usually rely onspecific entities to resolve an application-layer request into the IP address of a node able to performthe computation [34].

Besides overhauling interest and data packets, further modifications are required to let NDNsupport in-network computation. So far, the related literature has focused on the following maindesign aspects:

• Naming schemes for identifying both contents and services [6,36,37].• Discovery schemes for allowing NDN nodes to identify services and resources supported by their

neighbours, e.g., CPU, energy, and storage [8,34].• Service orchestration strategies to identify the best in-network service executors [6–10].

Future Internet 2019, 11, 222 7 of 21

• Security support in order (i) to authenticate the consumers asking for a service and (ii) to allow theexecutor to sign the computation result to make it verifiable by the consumer [37,38].

• Privacy-preserving schemes ensuring that results of computation inherit the same confidentiality ofthe input contents [39].

• Forwarding schemes for managing long and/or interactive computation [37] and for managing livestream processing [40].

In this paper, we consider a much less investigated topic, which is the problem of IoT serviceorchestration via NDN in a fog context. Basically, given a service request with known requirements,such as the associated CPU demand and processing deadline, the network has to find an NDNnode that can perform the service matching its requirements. This is a challenging objective sinceNDN nodes have usually limited and rapidly changing computing and storage resources and theallocation decision should be taken dynamically. Ad hoc designed mechanisms, closely tied to theNDN forwarding fabric, are therefore required that are different from the traditional cloud resourceorchestration strategies conceived so far [41].

4. IoT Service Orchestration via NDN

In this section, we review the IoT service orchestration mechanisms via NDN available in theliterature by identifying their features together with their pros and cons. In order to match the NDNmechanisms and to make the best of them, the majority of the proposals include a distributed serviceorchestration, according to which service allocation decision is taken in the network. However, thereare also a few examples of centralized designs, which we report for the sake of completeness. Scannedliterature works are summarized in Table 1.

Table 1. IoT service orchestration mechanisms in NDN.

Mechanism Type Short description

NFN FoX [6] Distributed First, it tries to find a cached result on the path towardsthe data source. In case of failure, the computation isperformed as close as possible to the data source or it ispushed into a node/server off-path.

NFN EdgeFox [10] Distributed Customizes FoX for edge domains, where nodes advertisethe availability of the functions they provide, and they arequeried for the result.

NFN FaX [10] Distributed The computation is started in the first available edgenode, and it is stopped if a cached result is found in themeanwhile.

IoT-NCN [7] Distributed The cost of IoT service execution is computed by on-pathnodes, according to a weighted function that takes as inputthe closeness cost and the processing cost. The node withthe lowest cost is selected as the executor.

NDN edge computing [34] Distributed The less congested node is selected as the executor.

CS-Man [42,43] Centralized A service manager is in charge of identifying the executorsof IoT services according to their capabilities.

ICN-isapiens [44,45] Centralized A software component called deployer is in charge ofloading the IoT services in specific fog nodes dependingon the physical IoT devices they control.

4.1. Distributed Mechanisms

A pioneering work extending NDN to support distributed in-network computations, with aspecial focus on IoT at the edge, is Named Function Networking (NFN) [6,10,46]. In NFN, a name canrepresent a content, a function capable of processing the content, or an expression combining both.

Future Internet 2019, 11, 222 8 of 21

The NDN forwarding engine is augmented with a λ-expression resolution system, which processes allinterests that have the postfix name component /NFN. Interest packets that do not carry the /NFNtag in the name field are treated as legacy requests for contents. A generic NFN name consists of thefollowing components:

[ccn : n f n| /name− o f − content| /name− o f − f unction]

For instance, a client requesting a video transcoded in a certain format can send an interest withthe following NFN name [6]:

[ccn : n f n| /name− o f − video| /name− o f − transconder]

The default NFN service orchestration strategy is called Find-or-Execute (FoX). First, the networktries to find a cached copy of the result, i.e., the transcoded video in the above example. Therefore,the request is forwarded towards the data producer, on path, according to the component /name−o f −media. If this search fails, FoX tries to compute the result in the NFN node n closer to the dataproducer. If not locally available, this node has to retrieve the content and the function code by sendingseparate interests for /name− o f −media and /name− o f − transconder. If n is not able to performthe service, it can push the computation towards another on-path node or even towards an off-pathnode, e.g., a cloud facility. In Reference [10], FoX is extended for orchestrating IoT services at the edge.The resulting EdgeFoX strategy assumes that nodes at the network edge are NFN capable and that theymay advertise the name of the functions they are able to execute. Similarly to FoX, the interest is firstforwarded towards the data source to find a cached result. In case of failure, the interest is forwardedto the NFN node owning the function to check for the result there. If this search also fails, then theresult is computed in the first available edge node, which should retrieve data and function codes.

The main problem with FoX and EdgeFox is a potential long service provisioning time due to thedifferent searching steps before starting the computation. This could negatively affect latency-sensitiveservices. Therefore, for the latter ones, to speed up the provisioning at the expenses of a largeroverhead, FoX is enhanced with the Find-and-Execute (FaX) strategy. In FaX, the computation isstarted immediately in the first available edge node and, in parallel, the interest is forwarded towardsthe data source to find a cached result. If the search is successful, the computation is stopped and theresult is forwarded to the consumer.

Although extremely promising in terms of targeted objectives and envisioned workflows, thementioned orchestration strategies in NFN have been only theoretically discussed so far and acomprehensive evaluation of their performance in a realistic network topology is still work in progress.A free software implementation of NFN, with Berkeley-style licence, is under development at theUniversity of Basel and it is available at www.named-function.net.

The work in Reference [34] shows the opportunities of enabling edge computing over NDN. Itassumes that fog nodes advertise the services they support and their resource utilization (e.g., CPU,GPU, memory, storage, and energy). Such information can be shared periodically in a proactive wayby using an NDN routing protocol like Named-Data Link State Routing Protocol (NLSR) [47] or ina reactive way at the reception of the request. The node with the lowest resource utilization canbe selected as executor. Such an approach targets well the fair distribution of computation effortsamong nodes in the edge domain. However, it accounts neither for the closeness to the raw data to beprocessed nor for the time needed to collect them.

In Reference [7], a more sophisticated IoT service orchestration strategy called IoT NamedComputation Networking (IoT-NCN) is proposed. There, service execution is assigned to the edgenodes in order (i) to limit the raw IoT data traffic crossing the network and (ii) to not exceed theiravailable processing resources. A weighted function is defined to compute the cost of service executionat the edge nodes on the path towards the data source, which well balances the aforementionedobjectives. Two costs are included in the function: the closeness cost, expressing the distance of thepotential executor to the data source, and the processing cost, expressing the processing capability of

Future Internet 2019, 11, 222 9 of 21

the potential executor with respect to the computing load required by the service. There, the candidateservice executors are limited to the on-path nodes, and the one offering the lowest cost is selected.The possibility to resort to the cloud is not investigated.

4.2. Centralized Mechanisms

In Reference [42], a centralized solution for service orchestration in NFN is provided that is calledComputation Service Management (CS-Man). The authors consider a static IoT network where aservice manager assigns tasks to other nodes according to their capabilities, as recorded in a databasecalled Service Repository. Despite the advantage of leveraging a centralized knowledge of the nodes’capabilities, in such a design, the service manager represents a single point of failure and a potentialbottleneck for the provisioning of services, as it is queried at every service request.

In References [44,45], a 3-level framework called ICN-isapiens is presented, where a fog layer,consisting of smart home servers (HSs), is introduced between the physical world and the remotecloud to support real-time services and to hide the heterogeneity of IoT devices. In ICN-isapiens, HSsare installed in houses and provided with a multi-agent software application to manage predefinedlow-latency monitoring and actuation services. Long-term storage and complex analysis are, instead,performed in the cloud. Each HS leverages NDN primitives to control a predefined set of IoT devices,while communication with the cloud is performed via IP. The application developers define theassociation between HS, IoT devices, and agents. Then, a system component called deployer is incharge to load the agents in the designed HSs and to start the system. As a result, ICN-isapiensdepend on a centralized component that assigns the agents and, therefore, the services to specificnodes and in a static fashion. Hence, it may lack the flexibility required to properly manage a dynamicfog environment.

4.3. Contribution

In this paper, we consider an NDN architecture for fog services provisioning in a smart campusscenario. Such a choice is to provide insights into the benefits of the proposal on a small scale but alsoa highly representative IoT smart environment, where the collection and processing of measurementsprovided by heterogeneous entities, such as consumer devices and building facilities, may be frequent.Unlike the works in References [42–45], which promoted a centralized service orchestration mechanism,we deploy a fully distributed strategy, more aligned with the NDN forwarding fabric.

Moreover, unlike the previously discussed works on distributed service orchestration [6,7,10,34],which mainly focused on an NDN edge scenario, here, we consider the interactions between the edgenodes and the cloud computing facilities, in alignment with the cloud-to-things continuum concept offog computing. In the conceived framework, NDN nodes first try to execute computing services alongthe path towards the data providers and, in case of failure, they delegate the services to the cloudor to a node in the path towards it in a transparent manner for the consumer. A novel forwardingstrategy is defined to support such a process, which requires minor modifications in the NDN node’sarchitecture. The service executor selection policy targets the minimization of the service provisioningtime, accounting for the data retrieval time and the processing time.

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 buildingscomposing a university campus. This is a smart environment where multiple NDN IoT devicesare installed that sense and monitor the environment and produce a variety of data. They can rangefrom 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 areasof the buildings.

Future Internet 2019, 11, 222 10 of 21

Without loss of generality, in the following, we define as IoT service an operation that takes asinput the raw data generated by the NDN IoT devices and processes them according to a certaincomputing function. The output of the computation is generally referred to as service result. It can becomposed of a single data packet, e.g., a float value indicating the average temperature in a room or aboolean value indicating if there are movements in an area, or multiple data packets, e.g., a compressedvideo or a dataset indicating the average, maximum, and minimum humidity values in a room.

Figure 2. Reference campus network topology.

Generally, there are no restrictions in the way a function must be implemented. According tothe literature, functions are generic software programs that can be in the form of unikernel, as inReference [8], or containers, as in Reference [42], or even λ-expressions. In the following, we assumethat a function is a self-consistent code, identified by a unique name and with a well-defined list ofoptional input parameters, which can be specified by the consumer; otherwise, a default value willbe used.

For instance, a simple function computing the average over a set of float values is named avgFand takes as input a number of s float samples over which the average is computed. If not specified,the default value s = 2 is considered. Instead, a function compressing flac audio files into mp3 files isnamed flacToMp3 and takes as input the kilobits per second value, which identifies the quality of thecompression (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 threedistinct parts: the content name, the function name, and the input parameters. While the first twocomponents are mandatory, the last one is optional. The tag EXEC is used for separating the contentand the function names. For instance, the name

campus/building1/floor4/classroomA/temp/EXEC/avgF/{s=5}

identifies a service that computes the average value over 5 temperature measurements collected fromsensors 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 thatcarry the service name. Of course, consumers can also request raw (non-processed) contents by

Future Internet 2019, 11, 222 11 of 21

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 anamed 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 thatconnects the IoT devices with a set of infrastructure elements acting as NDN content routers and fognodes, which in the following is referred to as NDN-fog nodes. In addition to the traditional routingand forwarding operations, they are provided with storage and processing capabilities to dynamicallyoffer 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 edgedomain 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 remotelyin the cloud.

5.2. NDN-Fog Node Design

As shown in Figure 3, NDN-fog nodes implement the legacy NDN data plane, while the controlplane is extended with a Service Decision Engine (SDE) that coordinates the following functionalities:

• Function storing module decides which functions should be installed in the node and whichfunctions should be evicted. The selection is performed in a proactive way by following apopularity-based approach, similar to Reference [8]. During the network bootstrap, a first manualconfiguration is performed by the network administrator, who may also decide that specificfunctions must be installed only in specific locations, e.g., for privacy purposes. When a functionis available in the node, a FIB entry is configured that binds the function name with the AppFaceof the node.

• Service allocation module decides, after the service interest reception, if the node can execute theservice and manages the signalling related to this operation.

Figure 3. Architecture of NDN-fog nodes.

NDN-fog nodes can dynamically download the function code from the so-called Function DataBase, a storage unit located in the campus domain that contains the function catalog. A default route isinstalled in the FIBs of the NDN-fog nodes towards the Function Data Base; thus, functions can beretrieved by name with the standard NDN interest/data exchange. Of course, if the function codeis available in the CS of an on-path node, the latter can directly satisfy the request without furtherforwarding it.

Future Internet 2019, 11, 222 12 of 21

5.3. Service Provisioning

Service provisioning is performed on demand when service interest packets are sent by consumerapplications. The latter are hosted in end-devices (e.g., users’ smartphones or laptops, monitoringutilities, etc.) connected to the leaf nodes of the campus network. When receiving the request, eachNDN-fog node applies a processing routine to discover if the result is already cached locally or if itselfcan be a candidate service executor. The service interest processing includes a bidding procedure thataims at executing the service at the edge in the best available NDN-fog node, which is the one offeringthe lowest service provisioning time. The latter is computed as the sum of the estimated processing timeand the IoT data collection time.

The processing time is estimated according to the currently available node’s resources, as providedby a standard CPU monitoring utility available in the node, once the CPU requirements of the serviceare known. The IoT data collection is estimated by reading the routing cost from the FIB entry per therequested content name.

The estimated service processing time is included in a new header field of the service interest thatwe call SPT. The consumer sets the SPT field in the interest to an upper bound value, which representsthe time of executing the service in the remote cloud. The parameter is overwritten by an NDN-fognode 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. Asa result, two different forwarding steps are foreseen.

First, the service interest is forwarded in the campus network towards the IoT producer and thediscovery is performed by on-path NDN-fog nodes. If the on-path search fails, then the second stepstarts and the service interest is forwarded towards the cloud. During this stage, newly traversedNDN-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 connectedto the IoT data producer, which in the following is referred to as Producer Access Node (PAN). In casethe consumer and producer have the same access node (CAN = PAN), then the candidate on-pathexecutor is just this single node.

Forwarding is guided by the first component of the hierarchical service name, that is, the contentname. Specifically, when the CAN or a subsequent NDN-fog node (let us call it Ni) receives the serviceinterest, the following processing is performed.

• First, Ni looks in the CS for a matching name. If it is found, it means that the same service hasbeen 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 servicehas been requested and it is pending. Therefore, Ni updates the correspondent PIT entry with theincoming service interest face and discards the packet.

• If the PIT matching fails, then the interest is processed by the SDE, which computes the serviceprovisioning time and decides if Ni can candidate itself for the execution. This choice dependson the available computing resources and the implemented service allocation strategy, as it willbe clarified in the following section. If the locally computed service provisioning time is loweror equal than the value already included in the SPT field, then Ni becomes the potential serviceexecutor: the SDE updates the SPT field and creates a new PIT entry that includes as additionalrecord the service provisioning time. Then, the packet is forwarded to the next node towards theIoT provider (and, therefore, towards the PAN).

After applying the service interest processing, the PAN acts as follows:

Future Internet 2019, 11, 222 13 of 21

1. If no on-path node is available for the execution, it sends back a NACK packet advertising thatthe service has not been allocated.

2. 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 andthe correspondent SPT. The first node with the correspondent SPT in the PIT will act as theexecutor.

5.3.2. Forwarding towards the Cloud

This forwarding stage is performed only if the service has not been allocated in the path betweenCAN and PAN, i.e., the service provisioning time offered by the cloud is shorter than the one offeredby on-path NDN-fog nodes.

Specifically, the NACK packet is forwarded hop-by-hop back to the CAN, which starts theforwarding 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 nameprefix, the request is now forwarded towards the cloud and, therefore, it will reach the root node. EachNDN-fog node receiving the service interest applies the previously discussed processing and evaluatesthe service provisioning time.

The procedure continues until the interest reaches the root node, which acts in a way slightlysimilar to the PAN: (i) if no node is available for the execution, the service interest is finally forwardedtowards the cloud; (ii) otherwise, the node with the lowest service provisioning time is selected as theexecutor 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 toyexample reported in Figure 4.

Service executed on-path: A consumer C transmits a service interest (labeled S-INTEREST inFigure 4a) to request a named service which is routed towards the data provider, P. The issued interestconveys 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 currentvalue of the SPT field in the forwarded interest only if the time is lower than the one carried in thereceived interest. The interest is then forwarded until it reaches the PAN. In the example, the PAN isnot 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 thatadvertised the lowest SPT, it becomes the executor. Therefore, it starts the data retrieval from theIoT data producer through legacy NDN interest/data packets. Once data are collected, the executorperforms the requested computation and sends the result to the consumer using the same name as theoriginal service interest.

Service executed off-path: In such a case (Figure 4b), the NDN-fog nodes of the domain cannotensure a service provisioning time shorter than the cloud; hence, a NACK is sent back by the on-pathnodes. The CAN, then, issues a service interest towards the cloud. All nodes forward the packet byoverwriting the SPT field whenever possible. The root node detects the availability of an executor (N2)and sends an ACK back. N2 is then in charge of retrieving data from the provider P and of sending theoutput of the computation to C.

Future Internet 2019, 11, 222 14 of 21

(a) Service executed in the path towards the IoT data producer.

(b) Service executed in the path towards the remote cloud.

Figure 4. Main steps of the interest/data exchange in NDN-fog.

6. Performance Evaluation

6.1. Simulation Settings

The behaviour of the conceived NDN-fog nodes in the campus network topology depictedin Figure 2 is evaluated in a realistic way by means of ndnSIMv2.5 [11], the official discrete-eventns-3-based simulator deployed by the NDN community.

We have modified ndnSIM from its stock installation to implement the features of NDN-fog nodesand the abovementioned allocation strategies.

We consider a catalog of 1000 services, each one requiring a randomly selected amount of CPUresources in the range [25–375] Mcycles. Similarly to Reference [49], since there are no datasetscontaining traces of the service workloads in real IoT scenarios, we assume that services are requestedaccording to a Zipf distribution with skewness parameter α set to 0.4 and 0.8. The request arrival ratefollows the Poisson distribution.

The following benchmarking schemes are considered:

Future Internet 2019, 11, 222 15 of 21

• Closest executor strategy (labeled as CE in the figures): Inspired by the work in Reference [10], itaims at executing the service as close as possible to the IoT providers.

• Least loaded executor strategy (labeled as LLE in the figures): It targets at selecting as the serviceexecutor the node with the lowest CPU usage, similarly to the work in Reference [34].

• Remote cloud (labeled as Cloud in the figures): It resembles the case when all services are executedin remote cloud facilities.

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 aconsumer to request the service until the output of the service execution is sent back (thusincluding the computation time at the executor).

• Offloading-to-the-cloud percentage is derived as the percentage of times the service is executed in theremote 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 thedomain 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.

Table 2. Main simulation settings.

Parameter Value

Number of services 1000Zipf’s parameter 0.4, 0.8Request arrival rate (λ) Varying (10–80 requests/s)CPU requests of services Uniformly distributed in [25, 750] McyclesEdge link latency [5, 10] msRTT to the cloud 50 ms, 100 ms, 150 msCPU node capabilities [250–1500] MHzContent size (σ) [500, 1000, 2000] 1024 large packets

6.2. Simulation Results

The first set of results, shown in Figure 5, report the service provisioning time for the comparedschemes under different workload settings in terms of size of the content to be processed (σ) andarrival 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 highprocessing loads compared to the edge nodes. The processing time contribution is negligible comparedto the latency incurred in retrieving the input content. In fact, the larger the content size, the higher theservice provisioning time.

The LLE strategy, on the contrary, is highly affected by parameter λ. The considered metric highlyincreases with λ. The LLE performance is superior to the one experienced by the cloud solution forsmall arrival rates. This is especially true for large content size settings. As λ increases, instead, theservice 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 timebefore the processing, which is inevitably experienced at the nodes close to the producers, is muchmore significant than the time required to retrieve the input content.

Our proposal outperforms the compared schemes under all the considered settings by scalingbetter with the size of the content and the arrival rate of service requests. However, due to the limitedavailable processing resources at the edge nodes, its performance approaches the one experienced inthe case of the remote cloud for high λ settings.

Future Internet 2019, 11, 222 16 of 21

The better performance of the proposal has to be ascribed to the possibility to select as candidateexecutors also nodes that are off-path, i.e., in the path towards the cloud (and not only in the onetowards the data producers) and the remote cloud itself, as the ultimate solution. This is confirmedby results in Figure 6. Notably, only a small percentage of services are offloaded to the cloud andonly when the parameter λ is large. The larger the content size, the lower the offloading-to-the-cloudpercentage. This is because the latency contribution due to content retrieval by IoT producers getsmore significant for the cloud.

10 20 30 40 50 60 70 80

λ [requests/s]

100

101

Se

rvic

e p

rovis

ion

ing

tim

e [

s]

(lo

gsca

le)

NDN-fog

Cloud

CE

LLE

(a) Content size = 500 packets

10 20 30 40 50 60 70 80

λ [requests/s]

100

101

Serv

ice p

rovis

ionin

g tim

e [s] (logscale

)

NDN-fog

Cloud

CE

LLE

(b) Content size = 1000 packets

10 20 30 40 50 60 70 80

λ [requests/s]

101

Serv

ice p

rovis

ionin

g tim

e [s] (logscale

)

NDN-fog

Cloud

CE

LLE

(c) Content size = 2000 packets

Figure 5. Service provisioning time when varying the service request arrival rate (λ) for differentcontent size settings (σ), α = 0.8.

10 20 30 40 50 60 70 80

λ [requests/s]

0

1

2

3

4

5

6

7

8

Off

loa

din

g-t

o-t

he

clo

ud

[%

]

σ=500

σ=1000

σ=2000

Figure 6. Offloading-to-the-cloud percentage for the NDN-fog solution when varying the servicerequest arrival rate (λ) for different content size settings (σ), α = 0.8.

Future Internet 2019, 11, 222 17 of 21

The supremacy of NDN-fog compared to the benchmark schemes is paid in terms of a largeramount of traffic generated in the domain, as shown in Table 3. For small content size settings, theintra-edge exchanged traffic for NDN-fog approaches values experienced by the cloud solution. As thecontent 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 thedata producers.

It is interesting to observe that improvements of the proposed solution compared to the consideredbenchmark schemes are still significant under less favourable settings in terms of service popularity,i.e., α = 0.4. 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 theones provided by the benchmark schemes (see Figure 7).

Table 3. Intra-edge exchanged traffic for different content size settings (σ), λ = 80 requests/s.

Content size NDN-fog Cloud CE LLE

α = 0.4 α = 0.8 α = 0.4 α = 0.8 α = 0.4 α = 0.8 α = 0.4 α = 0.8

500 packets 2012 1567.4 1945 1497.5 496.4 384.54 2018 1517.41000 packets 3572 2787.1 3884 2990.7 981.3 757.85 4024 3019.62000 packets 6759 5132.6 7764 5977.2 1951 1504.5 8053 6043

10 20 30 40 50 60 70 80

λ [requests/s]

100

101

Se

rvic

e p

rovis

ion

ing

tim

e [

s]

(lo

gsca

le)

NDN-fog

Cloud

CE

LLE

(a) Content size = 500 packets

10 20 30 40 50 60 70 80

λ [requests/s]

101

Se

rvic

e p

rovis

ion

ing

tim

e [

s]

(lo

gsca

le)

NDN-fog

Cloud

CE

LLE

(b) Content size = 1000 packets

10 20 30 40 50 60 70 80

λ [requests/s]

101

Se

rvic

e p

rovis

ion

ing

tim

e [

s]

(lo

gsca

le)

NDN-fog

Cloud

CE

LLE

(c) Content size = 2000 packets

Figure 7. Service provisioning time when varying the service request arrival rate (λ) for differentcontent size settings (σ), α = 0.4.

The larger processing load at NDN-fog nodes results in a larger percentage of services offloadedto the cloud compared to the previous case with α = 0.8; see Figure 8. The impact of different

Future Internet 2019, 11, 222 18 of 21

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 serviceprovisioning time. This is especially true as the input content size increases.

For what concerns the intra-edge traffic, the same trends already discussed for α = 0.8 can beobserved in Table 3. However, a higher traffic is exchanged due to the presence of less popular services.

10 20 30 40 50 60 70 80

λ [requests/s]

0

5

10

15

20

25

30

35

40

45

50

Off

loa

din

g-t

o-t

he

clo

ud

[%

]

σ=500, RTT=50ms

σ=500, RTT=100ms

σ=500, RTT=150ms

σ=2000, RTT=50ms

σ=2000, RTT=100ms

σ=2000, RTT=150ms

Figure 8. Offloading-to-the cloud percentage for the NDN-fog solution when varying the servicerequest arrival rate (λ) for different content size (σ) and round-trip-time (RTT) settings, α = 0.4.

7. Conclusions and Future Work

In this paper, we have discussed the potential of NDN to support fog computing in smartenvironments. After scanning the relevant literature, our proposal has been presented that is tailoredwithout loss of generality to the representative IoT smart campus scenario. We have proposed a serviceorchestration mechanism which is fully aligned with the fog computing concept. Indeed, it supportsthe decision of whether the IoT data processing has to be performed at the edge or remotely in thecloud 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 solutionsunder 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 conditionholds 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 achievedreduction of the service provisioning time, which is well below 10 s for NDN-fog under all theconsidered settings.

All in all, the proposal adequately targets a user-centric policy which values more how theconsumers perceive the services in terms of service provisioning time, in our case, than the incurredtraffic 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 alsoconsidering services with different priorities. Moreover, we plan to investigate the integration of theNDN fog computing paradigm with other emerging techniques, such as software-defined networking(SDN) and network function virtualization (NFV).

Author Contributions: In this paper, M.A., G.R., C.C., and A.M. conceived the idea. G.R., M.A., and C.C.conceived and designed the experiments; M.A. and G.R. performed the experiments. All the authors (M.A., G.R.,C.C., A.M., V.L., C.T.C.) organized the work; analyzed the experiments; and reviewed the writing of the paper, itsstructure, and its intellectual content.

Funding: This research was partially funded by the Italian Government under grant PON ARS01_00836 for theCOGITO (A COGnItive dynamic sysTem to allOw buildings to learn and adapt) PON Project.

Future Internet 2019, 11, 222 19 of 21

Conflicts of Interest: The authors declare no conflict of interest. The funders had no role in the design of thestudy; in the collection, analyses, or interpretation of data; in the writing of the manuscript; or in the decision topublish the results.

Abbreviations

The following abbreviations are used in this manuscript:

AppFace Application FaceCS Content StoreFIB Forwarding Information BaseICN Information Centric NetworkingIEC International Electrotechnical CommissionIoT Internet of ThingsISO International Organization for StandardizationNetDeviceFace Network Device FaceNCN Named Computation NetworkingNDN Named Data NetworkingNFN Named Function NetworkingPIT Pending Interest TableRIB Routing Information BaseRTT Round Trip TimeSCT Strategy Choice TableSDE Service Decision Engine

References

1. Lee, I.; Lee, K. The Internet of Things (IoT): Applications, investments, and challenges for enterprises.Bus. Horizons 2015, 58, 431–440. [CrossRef]

2. Cicirelli, F.; Guerrieri, A.; Spezzano, G.; Vinci, A.; Briante, O.; Iera, A.; Ruggeri, G. Edge computing and socialinternet of things for large-scale smart environments development. IEEE Internet Things J. 2017, 5, 2557–2571.[CrossRef]

3. Chiang, M.; Zhang, T. Fog and IoT: An overview of research opportunities. IEEE Internet Things J. 2016,3, 854–864. [CrossRef]

4. OFC. Openfog Consortium. Available online: http://www.openfogconsortium.org/ (accessed on 30September 2019).

5. Zhang, L.; Afanasyev, A.; Burke, J.; Jacobson, V.; Crowley, P.; Papadopoulos, C.; Wang, L.; Zhang, B. NamedData Networking. ACM SIGCOMM Comput. Commun. Rev. 2014, 44, 66–73. [CrossRef]

6. Tschudin, C.; Sifalakis, M. Named functions and cached computations. In Proceedings of the 2014 IEEE 11thConsumer Communications and Networking Conference (CCNC), Las Vegas, NV, USA, 10–13 Janary 2014 .

7. Amadeo, M.; Ruggeri, G.; Campolo, C.; Molinaro, A. IoT Services Allocation at the Edge via Named DataNetworking: From Optimal Bounds to Practical Design. IEEE Trans. Netw. Serv. Manag. 2019, 16, 661–674.[CrossRef]

8. Król, M.; Psaras, I. NFaaS: Named function as a service. In Proceedings of the 4th ACM Conference onInformation-Centric Networking, Berlin, Germany, 26–28 September 2017.

9. Ascigil, O.; Reñé, S.; Xylomenos, G.; Psaras, I.; Pavlou, G. A keyword-based ICN-IoT platform. In Proceedingsof the 4th ACM Conference on Information-Centric Networking, Berlin, Germany, 26–28 September 2017.

10. Scherb, C.; Grewe, D.; Wagner, M.; Tschudin, C. Resolution strategies for networking the IoT at the edge vianamed functions. In Proceedings of the 2018 15th IEEE Annual Consumer Communications & NetworkingConference (CCNC), Las Vegas, NV, USA, 12–15 January 2018.

11. Mastorakis, S.; Afanasyev, A.; Moiseenko, I.; Zhang, L. ndnSIM 2.0: A New Version of the NDN Simulator forNS-3. Available online: https://www.researchgate.net/profile/Spyridon_Mastorakis/publication/281652451_ndnSIM_20_A_new_version_of_the_NDN_simulator_for_NS-3/links/5b196020a6fdcca67b63660d/ndnSIM-20-A-new-version-of-the-NDN-simulator-for-NS-3.pdf (accessed on 22 October 2019).

Future Internet 2019, 11, 222 20 of 21

12. Ahlgren, B.; Dannewitz, C.; Imbrenda, C.; Kutscher, D.; Ohlman, B. A Survey of Information-centricNetworking. IEEE Commun. Mag. 2012, 50, 26–36. [CrossRef]

13. Afanasyev, A.; Shi, J.; Zhang, B.; Zhang, L.; Moiseenko, I.; Yu, Y.; Shang, W.; Li, Y.; Mastorakis, S.; Huang, Y.;et al. NFD Developer’s Guide. Available online: https://named-data.net/wp-content/uploads/2016/03/ndn-0021-diff-5..6-nfd-developer-guide.pdf (accessed on 22 October 2019).

14. Piro, G.; Amadeo, M.; Boggia, G.; Campolo, C.; Grieco, L.A.; Molinaro, A.; Ruggeri, G. Gazing into thecrystal ball: When the future internet meets the mobile clouds. IEEE Trans. Cloud Comput. 2016, 7, 210–223.[CrossRef]

15. Zhang, G.; Li, Y.; Lin, T. Caching in Information Centric Networking: A Survey. Comput. Netw. 2013, 57,3128–3141. [CrossRef]

16. Yi, C.; Afanasyev, A.; Moiseenko, I.; Wang, L.; Zhang, B.; Zhang, L. A case for stateful forwarding plane.Comput. Commun. 2013, 36, 779–791. [CrossRef]

17. Shang, W.; Bannis, A.; Liang, T.; Wang, Z.; Yu, Y.; Afanasyev, A.; Thompson, J.; Burke, J.; Zhang, B.; Zhang,L. Named Data Networking of Things. In Proceedings of the IEEE First International Conference onInternet-of-Things Design and Implementation (IoTDI), Berlin, Germany, 4–8 April 2016.

18. Baccelli, E.; Mehlis, C.; Hahm, O.; Schmidt, T.C.; Wählisch, M. Information centric networking in the IoT:Experiments with NDN in the wild. In Proceedings of the 1st ACM Conference on Information-CentricNetworking, Paris, France, 24–26 September 2014.

19. Amadeo, M.; Campolo, C.; Iera, A.; Molinaro, A. Information Centric Networking in IoT scenarios: The caseof a smart home. In Proceedings of the IEEE International Conference on Communications (ICC), London,UK, 8–12 June 2015.

20. Burke, J.; Gasti, P.; Nathan, N.; Tsudik, G. Securing instrumented environments over content-centricnetworking: The case of lighting control and NDN. In Proceedings of the 2013 IEEE Conference on ComputerCommunications Workshops (INFOCOM WKSHPS), Turin, Italy, 14–19 April 2013 .

21. Amadeo, M.; Briante, O.; Campolo, C.; Molinaro, A.; Ruggeri, G. Information-centric networking for M2Mcommunications: Design and deployment. Comput. Commun. 2016, 89, 105–116. [CrossRef]

22. Tourani, R.; Misra, S.; Mick, T.; Panwar, G. Security, privacy, and access control in information-centricnetworking: A survey. IEEE Commun. Surv. Tutor. 2018, 20, 566–600. [CrossRef]

23. Shang, W.; Yu, Y.; Liang, T.; Zhang, B.; Zhang, L. Ndn-ace: Access Control for Constrained Environmentsover Named Data Networking. Available online: http://new.named-data.net/wp-content/uploads/2015/12/ndn-0036-1-ndn-ace.pdf (accessed on 22 October 2019).

24. Zhang, Z.; Yu, Y.; Zhang, H.; Newberry, E.; Mastorakis, S.; Li, Y.; Afanasyev, A.; Zhang, L. An overview ofsecurity support in Named Data Networking. IEEE Commun. Mag. 2018, 56, 62–68. [CrossRef]

25. Bonomi, F.; Milito, R.; Zhu, J.; Addepalli, S. Fog computing and its role in the internet of things. In Proceedingsof the First Edition of the MCC Workshop on Mobile Cloud Computing, Helsinki, Finland, 17 August 2012.

26. Fog Computing and the Internet of Things: Extend the Cloud to Where the Things Are. Cisco White Paper.Available online: https://www.cisco.com/c/dam/en_us/solutions/trends/iot/docs/computing-overview.pdf (accessed on 22 October 2019).

27. Aazam, M.; Zeadally, S.; Harras, K.A. Deploying fog computing in industrial internet of things and industry4.0. IEEE Trans. Ind. Inform. 2018, 14, 4674–4682. [CrossRef]

28. Hou, X.; Li, Y.; Chen, M.; Wu, D.; Jin, D.; Chen, S. Vehicular fog computing: A viewpoint of vehicles as theinfrastructures. IEEE Trans. Veh. Tech. 2016, 65, 3860–3873. [CrossRef]

29. Menon, V.G.; Prathap, J. Vehicular fog computing: challenges applications and future directions. In FogComputing: Breakthroughs in Research and Practice; IGI Global: Hershey, PA, USA, 2018; pp. 220–229.

30. Yousefpour, A.; Fung, C.; Nguyen, T.; Kadiyala, K.; Jalali, F.; Niakanlahiji, A.; Kong, J.; Jue, J.P. All one needsto know about fog computing and related edge computing paradigms: A complete survey. J. Syst. Archit.2019, 98, 289–330. [CrossRef]

31. Baktir, A.C.; Ozgovde, A.; Ersoy, C. How can edge computing benefit from software-defined networking: Asurvey, use cases, and future directions. IEEE Commun. Surv. Tutor. 2017, 19, 2359–2391. [CrossRef]

32. Duan, Q.; Yan, Y.; Vasilakos, A.V. A survey on service-oriented network virtualization toward convergenceof networking and cloud computing. IEEE Trans. Netw. Serv. Manag. 2012, 9, 373–392. [CrossRef]

Future Internet 2019, 11, 222 21 of 21

33. Gedeon, J.; Meurisch, C.; Bhat, D.; Stein, M.; Wang, L.; Mühlhäuser, M. Router-based brokering for surrogatediscovery in edge computing. In Proceedings of the 2017 IEEE 37th International Conference on DistributedComputing Systems Workshops (ICDCSW), Atlanta, GA, USA, 5–8 June 2017.

34. Mtibaa, A.; Tourani, R.; Misra, S.; Burke, J.; Zhang, L. Towards Edge Computing over Named DataNetworking. In Proceedings of the 2018 IEEE International Conference on Edge Computing (EDGE),San Francisco, CA, USA, 2–7 July 2018 .

35. Amadeo, M.; Campolo, C.; Molinaro, A. NDNe: Enhancing Named Data Networking to SupportCloudification at the Edge. IEEE Commun. Lett. 2016, 20, 2264–2267. [CrossRef]

36. Amadeo, M.; Campolo, C.; Molinaro, A.; Ruggeri, G. IoT data processing at the edge with Named DataNetworking. In Proceedings of the 24th European Wireless Conference, Catania, Italy, 2–4 May 2018.

37. Król, M.; Habak, K.; Oran, D.; Kutscher, D.; Psaras, I. Rice: Remote method invocation in icn. In Proceedingsof the 5th ACM Conference on Information-Centric Networking, Boston, MA, USA, 21–23 September 2018.

38. Krol, M.; Marxer, C.; Grewe, D.; Psaras, I.; Tschudin, C. Open security issues for edge named functionenvironments. IEEE Commun. Mag. 2018, 56, 69–75. [CrossRef]

39. Marxer, C.; Scherb, C.; Tschudin, C. Access-controlled in-network processing of named data. In Proceedingsof the 3rd ACM Conference on Information-Centric Networking, Kyoto, Japan, 26–28 September 2016.

40. Scherb, C.; Marxer, C.; Schnurrenberger, U.; Tschudin, C. In-network live stream processing with namedfunctions. In Proceedings of the IFIP Networking Conference and Workshops, Stockholm, Sweden, 12–16June 2017.

41. Liu, C.; Loo, B.T.; Mao, Y. Declarative automated cloud resource orchestration. In Proceedings of the 2ndACM Symposium on Cloud Computing, Cascais, Portugal, 26–28 October 2011; p. 26.

42. Wang, Q.; Lee, B.; Murray, N.; Qiao, Y. CS-Man: Computation service management for IoT in-networkprocessing. In Proceedings of the 2016 27th Irish Signals and Systems Conference (ISSC), London, UK, 21–22June 2016.

43. Wang, Q.; Lee, B.; Murray, N.; Qiao, Y. IProIoT: An in-network processing framework for IoT usingInformation Centric Networking. In Proceedings of the 2017 Ninth International Conference on Ubiquitousand Future Networks (ICUFN), Milan, Italy, 4–7 July 2017.

44. Amadeo, M.; Molinaro, A.; Paratore, S.Y.; Altomare, A.; Giordano, A.; Mastroianni, C. A Cloud of Thingsframework for smart home services based on Information Centric Networking. In Proceedings of the IEEE14th International Conference on Networking, Sensing and Control (ICNSC), Calabria, Italy, 16–18 May 2017.

45. Amadeo, M.; Giordano, A.; Mastroianni, C.; Molinaro, A. On the integration of information centricnetworking and fog computing for smart home services. In The Internet of Things for Smart Urban Ecosystems;Springer: Cham, Switzerland, 2019; pp. 75–93.

46. Scherb, C.; Tschudin, C. Smart Execution Strategy Selection for Multi Tier Execution in Named FunctionNetworking. In Proceedings of the 2018 IEEE International Conference on Communications Workshops (ICCWorkshops), Kansas City, MO, USA, 20–24 May 2018.

47. Hoque, A.; Amin, S.O.; Alyyan, A.; Zhang, B.; Zhang, L.; Wang, L. NLSR: Named-data link state routingprotocol. In Proceedings of the ACM SIGCOMM Workshop on Information-Centric Networking, Hong Kong,China, 12 August 2013; pp. 15–20.

48. ISO/IEC. 11801-2:2017 Information Technology—Generic Cabling for Customer Premises. 2017. Availableonline: https://www.iso.org/standard/66183.html (accessed on 22 October 2019).

49. Elbamby, M.S.; Bennis, M.; Saad, W. Proactive edge computing in latency-constrained fog networks.In Proceedings of the 2017 European conference on networks and communications (EuCNC), Oulu, Finland,12–15 June 2017.

c© 2019 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open accessarticle distributed under the terms and conditions of the Creative Commons Attribution(CC BY) license (http://creativecommons.org/licenses/by/4.0/).