1. Introduction

Cloud computing (CC) technology provides computing and storage services to users in datacenters that are multiple hops away from the user's devices or data sources ^[1]. CC becomes problematic when latency-sensitive Internet of Things (IoT) applications demand quick response to take instantaneous measures as every time the request has to travel back to the cloud node, increasing backhaul network traffic and congestion, which ultimately increase the delay. To overcome latency issues incurred by the CC paradigm, the edge computing (EC) concept was introduced by the European Telecommunication Standards Institute (ETSI), which provides computation, storage, and network optimization at the edge of the network in closer proximity to IoT devices with fast processing capabilities and quick response. The realization of EC can be divided into three models: 1) fog computing (FC), 2) cloudlets (CLs), and 3) mobile edge computing (MEC).

FC brings services and applications closer to users, and data processing takes place locally on fog nodes rather than in the Cloud data center. It also supports delay sensitivity, caching, offloading, location awareness, and mobility. A CL is a small-scale data center and it brings the computation resources closer to the user’s vicinity. CLs are located at the edge and provide services to mobile applications with lower latency. The MEC integrates Cloud computing functionalities in mobile networks. Initially, it was intended for mobile networks, but later on, it was used by fixed and mobile networks and provides EC services.

Although EC exhibits strong potential to resolve various challenges of modern-day communication, its current implementation is built on top of an inefficient address-based communication model that often creates several issues, especially in highly dynamic and complex scenarios. For instance, the current Internet Protocol (IP)-based communication model assigns unique addresses to every node in the network, which may exhaust the limited address space of both IPv4 and IPv6 in the future. Additionally, the long IPv6 addresses are not suitable for every kind of node (for instance, constraint-oriented nodes) in the network, so it makes address-based communication even less suitable to fulfill future communication requirements. Moreover, from a data perspective, IoT end-users are always interested in fetching the updated information rather than the address or the location of the information source.

To resolve such issues, NDN ^[2], a realization of Information-Centric Networking (ICN), has appeared as an alternative solution. Various other architectures have been proposed under the umbrella of ICN to replace the address-oriented philosophy with a content-oriented one, such as 4WARD ^[3,4], PSIRP ^[5], SAIL ^[6], PURSUIT ^[7], and CCN ^[8]. However, NDN has gained much interest from both academia and industry. NDN employs names rather than addresses to fetch the content from the network and eliminate the need for end-to-end connection between source and destination nodes. NDN offers many attractive features, such as in-network caching, request aggregation, multi-homing, and requester mobility. If combine with EC, these features efficiently resolve the issues incurred by the traditional address-based communication model.

This paper presents a survey of various techniques proposed in the literature that integrate EC with NDN. The aim is to provide maximum performance with ultra-low latency, efficient content distribution, scalability, and security in the network. The overall contributions of this paper are the following:

$\textbf{·}$ An overview of NDN forwarding is highlighted, and EC is presented with its fundamentals.

$\textbf{·}$ A comprehensive survey of studies and approaches proposed in the literature that combine ICN with EC services is discussed.

$\textbf{·}$ A comparative description of ICN-based EC strategies considered is also presented in a tabular form that differentiates the studies' contributions in terms of naming, routing, forwarding, mobility, and security.

$\textbf{·}$ In the end, the open research issues are presented with the difficulties that the researchers may face to achieve the best performance.

The rest of the paper is organized as follows. Section II briefly describes the fundamentals of NDN. An overview of the EC paradigm is outlined in Section III. Section IV discusses the various proposals available in the literature that integrate ICN with EC. Section V presents different research challenges in the domain of information-centric edge computing. Finally, we conclude the paper in section VI.

2. Named Data Networking: In a nutshell

The NDN forwarding process is presented in Fig. 1. NDN follows a pull-based model of communication, and the application layer name is forwarded directly to the network layer along the appropriate path for fetching the desired content. The NDN nodes maintain three data structures: 1) a pending interest table (PIT), 2) content store (CS), and 3) forwarding information base (FIB). A consumer puts the desired content name in the interest packet, and it is forwarded to the network. When an interest packet is received by a content router (CR) on an incoming interface, the CS is checked. If the requested data is available in CS, the request is satisfied, and a data packet is sent downstream.

If the requested data is not present in CS, then the PIT entries are checked for whether the requested name exists in the queue. Records of the PIT entry in and out are maintained in a single entry for every incoming and outgoing interest that was received but not satisfied yet. The interest packet’s incoming interface IDs are maintained in in-records, and out records’ interface IDs are maintained in out-records.

If a CR has a matching PIT entry, it updates the in-record and stores the incoming interface of the current request. However, if the PIT entry does not exist, the interest packet is forwarded to the producer using FIB long prefix matching. The FIB can have more than one interface for a single prefix name. Once the interest packet reaches the producer, it may respond with the content itself or content name. When the data packet arrives at a CR, it looks to the corresponding PIT entry and forwards data to all downstream interface IDs. Finally, it removes the PIT entry, and data is stored in CS.

Fig. 1. NDN Forwarding.

3. An overview of Edge Computing

CC offers centralized computing storage and network resources. Such clouds are referred to as Cloud data centers. Data centers work with IP networks, and the core is cellular networks. With the advent of cellular, tablets, and laptops, the demands for network services increased. Today's mobile devices are powerful but may not accommodate powerful applications like virtual reality (VR) and augmented reality (AR) ^[9]. To extend the battery life and accommodate such high processing applications, the mobile Cloud computing (MCC) concept was introduced ^[10]. The users can offload their tasks to Cloud data centers using the internet or cellular network.

The emergence of the IoT has made a large number of devices’ interconnections possible, and these devices generate a huge amount of data. Furthermore, applications like drone flight control, AR/VR, online gaming, and smart transportation require real-time processing with very low latency, even in milliseconds, and it creates challenges. To overcome such challenges, EC was introduced to bring services closer to the end-users, as demonstrated in Fig. 2. The first realization of EC ``Cloudlets'' was introduced in 2009 ^[11] that brings the computation resources to the users’ closer vicinity. Another concept of EC, fog computing (FC), was introduced by CISCO in 2012 ^[12]. FC brings, applications, and services closer to mobile users, and data processing takes place locally on fog devices rather than sending it to the Cloud for processing. It also supports caching, offloading, location awareness, mobility, and delay-sensitive applications. However, these EC proposals suffer from quality of experience (QoE) and quality of services (QoS). The reason behind this is that computing is not enabled for mobile networks.

To enable mobile networks with such applications and services, EC was introduced by the ETSI and named MEC ^[13]. MEC integrates Cloud functionalities in mobile networks. Initially, it was intended for mobile networks, but later on, it was used by mobile and fixed networks. Therefore, the acronym MEC no longer refers to Mobile Edge Computing, and now, it is known as Multiple Access Mobile Edge Computing ^[14]. Now, the concepts of edge, fog, MEC, MCC, and Cloudlets are under the umbrella of EC.

Fig. 2. Edge computing architecture.

4. Information-centric Edge Computing

In this section, we describe the NDN/ICN with EC integration techniques and proposals. We look in depth into how these approaches attempted NDN/ICN with edge integration. The authors in one study ^[15] proposed an IoT-Named Computing Networking strategy (IoT-NCN). The NDN architecture is extended for IoT data stream processing at the network edge. The network edge behavior turns into a dynamic computing environment for IoT applications in the data processing. Users' requests are managed by the network nodes with their available computing capabilities. In this technique, the naming and forwarding are defined in such a way that service requests are guided towards close EC nodes to deliver services with low latency and to avoid the flood of raw IoT data in the network. The performance of the proposal is evaluated by using the ndnSim simulation toolkit. Experiment results show that IoT-NCN outperforms in terms of reduction in traffic volume, exchanged data traffic, and service provisioning time.

In another study ^[16], researchers introduced a fog-to-fog horizontal layer with information-centric networking. An application in Fog-ICN transfers data horizontally in the fog layer and also distributes data computation in fog nodes. It supports built-in mobility and named based connectionless data communication. ICN-Fog reduces the services’ dependency on Cloud infrastructure. This approach has benefits for fog computing, which include better mobility, shorter latency, and higher data communication efficacy. NDN at the edge (NDNe) has been proposed ^[17] for Cloudification in the network edge framework. NDNe is more novel than existing techniques in terms of reducing the burden of developers by supporting name-based communication, interest-data exchange, and in-network caching to fit the targeted edge scenarios. A flexible naming makes it able to identify different cloud edge services and connectionless primitives support nearby service provider discovery with the required level.

The authors in another study ^[18] highlighted EC over NDN/ICN architectural opportunities. AR was utilized as a use case in this approach to demonstrate the advantages of NDN architecture in EC. They also discussed several solutions about compute reuse, resource discovery, security, and mobility management. Different design options and tradeoffs have also been discussed in this paper.

In another study ^[19], the Named Function as a Service (NFaaS) approach was proposed. NFaaS extends the NDN architecture that runs the functions in the network. It builds on lightweight virtual machines that support dynamic custom code execution. Any network node can download and run functions in the network, and functions can move in the network between nodes to meet users’ demands. A Kernel store component was introduced in NFaaS that stores functions and make decisions for local function execution. It also includes a routing protocol and several forwarding techniques that support function deployments and migrations within the network. To validate the designed approach, simulations were carried out, which demonstrate that the NFaaS deploys delay-sensitive functions closer to the edge and other functions closer to the core.

A pioneer Named Function Networking (NFN) ^[20] scheme was proposed by other authors. The authors extended the Named Data Network in NFN to the edge. In traditional NDN/ICN, the interest packets contain the name field of the content, while in NFN, they contain not only the name of content, but also expressions for named functions. The network plays the role of being in charge of computing the results and also resolves the forwarding plane of NDN. Several functions make NFN constrained in many scenarios like nodes in the network require sophisticated processing, libraries, and custom code, with which is complex to express simple expressions and having further function code.

To cope with the issue of IoT’s large data-volume generation at the network edge, a researcher in another study ^[21] designed an Information-Centric edge (ICedge) approach, which is a general framework that utilizes redundant computation at the edge. It runs on top of NDN and handles the low-level network communications on behalf of IoT applications. It is a fully distributed framework, and its features include seamlessly bringing users on-board to the edge node network, delivering application tasks to edge nodes for timely execution, and providing a network-based mechanism to enable users to use already executed tasks' results, which is called "compute reuse." This results in lower task completion time and more efficient use of edge resources.

An EC service model based on ICN has been proposed in another study ^[22], which is designed to support efficient EC service provision. In this scheme, a naming scheme and a push-based service session model were designed for edge services. Secondly, for appropriate edge server selection, two forwarding strategies are included, which achieve load balancing. Finally, they presented a real-world prototype. The proposed scheme was evaluated by using ndnSIM v2.7, and they found that the proposed solution outperforms existing approaches.

R.Ullah et al. ^[23] proposed an ICN-capable radio access network architecture for 5G EC. This architecture offers device to device (D2D) communication and supports the ICN application layer at the base station. Furthermore, caching of ICN/Edge is useful only for static content. Dynamic content requests have to traverse the core network to cease latency in 5G networks. To solve this issue, an ICN-naming-based content prefetching strategy was designed. The ndnSim toolkit was employed to validate the proposed scheme, and results showed that the scheme achieves a higher cache hit ratio and also lower delays as compared with traditional existing works on ICN for 5G.

In another study ^[24], a conceptual fog framework with ICN was introduced. The ICN is used as an API for ubiquitous computing. The ICN cache is taken to the edge nodes using Fog computing. It is achieved as an off-network cache by referring object names with IP. This practice makes available information access on Cloud in the IoE close to users. Fog is used as an edge processing node in the content store that depicts the caching and makes it available off-path. Fog in this proposal provides processing, computing, and storage at the edge with added benefits of heterogeneity for IoT.

A researcher in another study ^[25] proposed IoT equipment-assisted caching multimedia (EACM) for ICN for the improvement of user experience. To attain this, they designed location prediction and smart caching strategies using machine learning, which predicts user interest. In this way, the users’ interest content can be driven to the edge node from the server. Furthermore, for improved caching utilization, an optimized caching algorithm was designed. The experimental results showed that the proposed strategy outperforms in caching mobile multimedia content, which also optimized the cache hit ratio and minimized the access time as compared to existing approaches. In ICN architecture, data is stored in the content store, which enables a user to access data in closer proximity.

Routers have limited storage capacity, and the CS can suffer from massive content storage. To enhance the in-network data availability, Wang et al. ^[26] proposed a framework that uses fog computing as a middle layer for communication with the underlying network and global ICN network. Data is preprocessed and classified in the fog layer and then transferred to ICN. In this way, this approach can reduce the total amount of caching content by labeling the users’ shareable and dynamic data. This approach also proved that the limited CS capacity cannot be a profitable in-network caching form.

A disaster relief approach was designed by the authors in another study ^[27], which is a combination of Fog computing and ICN. It solves the problem of fast communication and emergency networking during earthquakes and other natural disasters. Their proposed idea is six degrees of separation theory (SDST), which achieves information-centric fog computing (ICFC) disaster relief. The aim was to model a network node’s relationship and to design a name-routing strategy by using SDST. The proposed strategy was evaluated against existing routing strategies in ICN, and they found that it helps to improve working efficiency in post-disaster scenarios.

Table 2 describes a summary of contributions of the existing research and studies. As naming, routing, caching, mobility, and security are core functionalities of ICN/NDN networking architecture, the existing literature mainly focuses on these core features to achieve efficient performance in the Edge with NDN integration. It is evident from the table that most of the proposals consider naming, routing, forwarding, and caching in their schemes, whereas mobility and security features are either treated superficially or used as the default implementation. As mobility and security are also equally important, further work in these directions is required to devise novel and efficient mobility and security solutions for the ICN-edge integrated architecture.

In Table 3, the pros and cons of the surveyed schemes are presented. At first, the pros are presented in terms of 1) load-balancing, 2) resource/data recovery, 3) QoS, and 4) maximum cache utilization. As QoS is the fundamental characteristic of ICN networking, most of the surveyed schemes fulfill the QoS demand in the ICN integrated Edge paradigm. In terms of load-balancing, almost 50% of schemes efficiently handle the workload on the edge node. Although efficient resource discovery is an important research area in ICN-based EC, only 5 surveyed schemes discussed the potential solutions. Similarly, only two schemes fully leveraged the caching feature of ICN.

Concerning the limitations, as is evident from Table 3, the major limitation is that most of these schemes target a specific environment such as disaster management and smart homes. Besides, these schemes require a specific type of input to work efficiently. However, such solutions cannot be utilized in all Edge or IoT environments. There are some other limitations, which include high processing time, limited scalability, long delays, and fixed packet size.

Delay sensitivity is crucial in real-time environments such as healthcare and smart industries; therefore, it cannot be ignored. High processing time also creates issues in the environments where quick response is required. Thus, the proposed environment-specific schemes do not scale well when the environment is changed. Despite this fact, most of the solutions proposed in the literature target a specific environment are prone to various scalability issues. Furthermore, some schemes assume fixed packet size for communication. However, it cannot be applied to all scenarios. Moreover, some of these schemes also ignored security concerns, despite being essential in edge-integrated ICN environments. Considering these pros and cons of the existing literature, in section V, we provide the open research issues and highlight the areas that require further research efforts to propose an efficient solution in edge with ICN-integrated architecture.

5. Open Research Issues

It is evident from the literature review in the previous section that the proposed schemes have paved the way for the integration of ICN with an edge. Despite this, there are still some constraints and challenges in the ICN integrated edge paradigm that need to be addressed efficiently. These challenges and constraints are described as follows.

$\textbf{1.Computing and Caching}$ are two core features of EC that enable the content and computations available in close proximity to end-users and/or IoT devices to speed up the retrieval process with minimal latency. However, the ICN-enabled intermediate network nodes may not be able to store and compute all the requests due to their limited resources, and as a result, some of the requests must be offloaded to the edge or cloud nodes. Keeping in mind these fundamental requirements and network constraints, the integration of ICN with EC brought forth various challenges, such as 1) what to cache locally on the intermediate network nodes since content-oriented IoT devices produce a huge amount of content, and 2) how to split the execution of computational requests among intermediate nodes and edge nodes to enable parallelism and to speed up the computational process. The edge nodes and the intermediate nodes should store meaningful data on a priority and popularity basis by conjunctionally deciding the optimal location of content storage. Moreover, an optimal decision-making strategy is also required to select and distribute the computational requests among ICN-enabled intermediate nodes and the EC nodes in an ICN and edge combined architecture.

$\textbf{2. Naming}$ for ICN-based EC is another open issue since in the ICN paradigm, the nodes access the services and contents by name, whereas the current EC architectures work using inefficient address-based IP. Therefore, new naming schemes are required that support ICN in edge or edge in ICN to facilitate accessibility, mobility, scalability, and security requirements.

$\textbf{3. Name Resolution}$ for assigning a unique name to each computational service and content may explode the naming space. As a result, the name resolution entities in the network may face various challenges, such as storage limitations, searching cost, and denial of services. Therefore, practical and flexible naming schemes are required that ease the burden on name resolution entities in edge with ICN architecture to achieve networking performance.

$\textbf{4. Routing and Forwarding}$ are other challenges in ICN with the EC paradigm. In ICN, interest packets are sent hop-by-hop by employing name-based FIB lookup on the intermediate forwarders, whereas in conventional EC, the forwarding and routing are based on address lookup. In ICN, the incoming data packet name is compared with the names in PIT, and on a successful match, the data packet is sent back to the consumer node by following the reverse path. In contrast, since the packet forwarding in EC is stateless, there is no guarantee that the data packet takes the same path from where the request arrived. Therefore, it is of utmost importance to design a novel and robust name-based routing and forwarding mechanism that efficiently routes the compute request/response packets in the ICN-integrated EC paradigm.

$\textbf{5. Mobility:}$ Efficient mobility management schemes are also required in Edge with the ICN paradigm. Consumer mobility is by default supported in ICN. However, the producer mobility is still a challenging task in both ICN and EC. There is a need to devise an efficient producer mobility scheme in ICN-integrated EC that tackles the issues that may arise due to the long-lived computational services.

$\textbf{6. Security}$ in ICN is implemented at the packet level, whereas in IP-based EC, it is managed at the channel level. The packet-level security in ICN utilizes the existing public key infrastructure (PKI)-based digital certificates to validate the authenticity and provenance of the content. To check whether the received content is valid, the consumer extracts the name from the key-locator field in the data packet that points to another data packet containing a certificate or public key. Once the path is obtained, a consumer forwards another interest packet to fetch the certificate, which might be available far away from the consumer. Such a validation technique is not well suited for EC. As in EC, the goal is to bring the content closer to the end-user to minimize the delay, and there should also be a mechanism to bring the certificates closer to reduce the delay in the verification process. To resolve such delay issues, further research is required in the ICN-based EC paradigm.

The above challenges need to be resolved to make ICN with edge-integrated architecture the best performance network.

6. Conclusion

NDN and EC are considered as the future internet technologies and gained much attention in the recent past. In this survey, we reviewed the existing approaches that integrate ICN with EC. At first, a brief description of the EC paradigm and an overview of NDN architecture along with its forwarding mechanism were presented. Secondly, this paper discussed the features and limitations of proposed schemes and provided a comprehensive comparison of these proposals. To this end, a comparative discussion also shed light on the key performance improvement factors, such as how these approaches achieve maximum performance by introducing the new algorithms and protocols that combine the ICN with EC. Finally, the challenges that still need to be addressed to attain maximum performance of ICN and EC synergy were also highlighted.