This article has been accepted for inclusion in a future issue of this magazine. Content is final as presented, with the exception of pagination.
ACCEPTED FROM OPEN CALL
A Distributed Cache Placement Scheme for Large-Scale Information-Centric Networking
Boubakr Nour, Hakima Khelifi, Hassine Moungla, Rasheed Hussain, and Nadra Guizani
Abstract
Information-Centric Networking (ICN) is a
promising candidate architecture for the future
Internet that leverages the content name instead
of the source of the content (host address). ICN
decouples the content from its original location
and owner, and enables in-network caching at
the network layer. Similarly, the inception of IoT
has enabled futuristic applications and services
in almost every walk of life. Due to the nature of
Internet of Things (IoT) applications, traditional
TCP/IP-based Internet architecture faces challenges such as addressing, heterogeneity, availability,
scalability, and resource constraints. Therefore,
ICN can be a suitable choice to address these
challenges in IoT applications. Among other
features of ICN, the in-network caching feature
increases the availability and efficiency of content-sharing in IoT networks. Therefore, it is essential to have efficient cache placement strategies in
ICN to increase its utility. In this regard, in this article, we propose an ICN cache placement strategy
at the edge network for IoT applications. More
precisely, we design a distributed cache placement scheme that aims to push the popular content to the edge network and keep the relatively
less-popular content at the core. We also propose
a collaborative mechanism to fetch content from
the nearest neighbor’s content-store as well as
propose a cache replacement policy based on
the content popularity. Through extensive simulations, we evaluate the proposed scheme and the
obtained results show the efficiency and out-performance against similar strategies in the literature.
Introduction
The necessity of sharing resources among communicating entities was one of the motivations
for developing the current Internet architecture.
In the communication architecture of the current
Internet, a dedicated session is always required
between the communicating entities (resource
requester and provider), where each entity in
the network is identified by a unique IP address.
This communication paradigm is known as the
host-centric model which provides perpetual connectivity. The existing host-centric communication model of Internet has shown great resilience
over the past decades to fulfill the communication
requirements of different applications. However, with the advancements in computation and
communication technologies, and access to highDigital Object Identifier:
10.1109/MNET.011.2000081
1
speed Internet, many futuristic applications surfaced that offer services in different sectors, for
instance, business, healthcare, industry, retail, and
finance, to name a few. These requirements and
user demands for application are shifting from a
host-oriented communication paradigm toward
content-oriented communication in terms of the
network requirements. In other words, content
delivery replaces the need to connect with the
host (content provider) through a communication
channel and session. This paradigm is referred to
as Information-Centric Networking (ICN) [1].
In ICN, communication is carried out on the
basis of content name instead of the location and
address of content’s source [2]. More precisely, ICN uses the content name for routing, forwarding, and security mechanisms. By using the
content name as the building block of the communication, ICN aims to decouple the content
from its original location and owner, and apply
security and access-control rules directly to the
content rather than to the communication channel and peers [3].
Such features enable ICN to share content
among nodes in an autonomous and seamless
fashion. Furthermore, ICN enables in-network
caching at the network layer instead of the application layer [4]. In essence, any ICN node can
cache the received content and serve future
requests from its local content-store rather than
forwarding requests to the original producer. This
phenomenon improves the content dissemination,
reduces network delay, enhances the content
distribution, and improves the quality of service.
Such transparent caching makes ICN a suitable
communication model for the future Internet.
Among other implementations of ICN architectures, Named Data Network (NDN) [5] is an
active and fast-growing ICN project that defines
three main data structures implemented by each
communicating node, that is, Content-Store (CS),
Pending Interest Table (PIT), and Forwarding
Information Base (FIB). The CS serves as a temporary cache for the content to satisfy the future
requests for the stored content. PIT keeps track
of the unsatisfied interests (more precisely the
interests that have been forwarded but the data
have not been received against these interests
yet). Lastly, FIB maintains the records of the suitable interface for each reachable name prefix.
On the other hand, Internet of Things (IoT)
[6] is poised to enable different applications in
many domains such as smart cities, smart buildings, smart industry, and so on, and has widely
Boubakr Nour (corresponding author) and Hakima Khelifi are with Beijing Institute of Technology; Hassine Moungla is with Université de Paris and also with
Institut Polytechnique de Paris; Rasheed Hussain is with Innopolis University; Nadra Guizani is with Washington State University.
0890-8044/20/$25.00 © 2020 IEEE
IEEE Network • Accepted for Publication
Authorized licensed use limited to: City, University of London. Downloaded on July 14,2020 at 04:57:43 UTC from IEEE Xplore. Restrictions apply.
This article has been accepted for inclusion in a future issue of this magazine. Content is final as presented, with the exception of pagination.
contributed to different real-time scenarios such
as remote appliance control and monitoring, location tracking, and remote monitoring and maintenance. IoT devices have the ability to sense,
collect, and store data. These devices can also
perform computations on the data and collaborate with each other over the Internet. To this
end, the current unprecedented achievements
in wireless communication, 5G and beyond
networks, edge computing, and intelligent data
analytics will augment the applicability of IoT.
However, many studies show that the complex
design of the current IP-based communication
model is not suitable for most IoT applications [7].
Therefore, a new communication paradigm that
focuses on the content is essentially needed for
IoT. In this regard, ICN can be a suitable candidate for IoT applications. More precisely, efficient
content naming, intrinsic security, mobility, and
in-network caching will help in addressing different IoT challenges [8, 9].
For efficient content dissemination in the network, every ICN node maintains a CS to store
the content based on different metrics. The CS
is managed through a Caching Replacement Policy (CRP) that defines the structure of cached
content and method(s) to evict the content from
the CS when no more cache memory is available for the content. On the other hand, Caching
Placement Strategy (CPS) aims to decide if the
received content should be cached by the current
node or not. Although different caching strategies have different objectives, their main objective
is to reduce the network load and decrease the
request latency. A content may be cached and
served by nodes existing in the communication
path (on-path) or in a dedicated server in the
cloud (off-path).
On-Path Caching: The nodes that are in the
content retrieval path make the caching decisions
and respond to the requests for content. A node
may respond to requests for content by utilizing
its own content-store, and can take caching decisions locally.
Off-Path Caching: This caching concept is similar to the Content Distribution Network (CDN)
where popular content is placed near consumers,
and all requests are forwarded to the CDN server.
A node may query a dedicated cache server or a
name resolution system to know the location of
the required cached content.
Caching data transparently at the network
layer is promising to enhance the overall network
performance. It avoids a single point of failure,
improves the content distribution in the network,
and reduces the network load and latency. However, a huge amount of content in the network
causes two problems for the in-network caching,
that is, deciding which content should be cached
and at which node. Our motivation behind this
work is to address these challenges. The contribution of our work is multi-fold. First we overview the content caching in ICN and review the
existing cache management solutions. Then, we
design a novel distributed scheme to push the
popular content to the edge of the network and
keep the less-popular content in the core of the
network. We also introduce a collaborative onehop cache notification to improve cache utilization from neighboring content-stores. Finally, we
Communication Path
ICN Network
R1
C1
R5
R3
R6
P
R4
R2
C2
FIGURE 1. In-network content caching in ICN.
carry out extensive simulations using ndnSIM to
prove the efficiency and efficacy of our proposed
mechanism with respect to the existing solutions.
Content Caching in ICN
In contrast to CDN, ICN decouples the content
from its original location and provides in-network
caching at the network layer [10–12]. This caching is totally transparent to both original content
producer and consumer(s). As depicted in Fig. 1,
an ICN node may cache content without informing the original producer, and fulfill the demands
for content from the local CS. ICN aims at
improving the network performance by speeding
up the content distribution in the network, reducing load on the original content provider, and
decreasing the latency incurred by content delivery. The caching plane is mainly divided into two
strategies: content placement and replacement. In
the following, we review the existing cache placement strategies, cache replacement policies, and
highlight the existing challenges and limitations.
Content Placement Strategies
Whenever an intermediate ICN node receives
content to deliver it downstream, a caching placement decision is required. This action consists of
a decision whether the said content should be
cached in the node’s CS or not. Various ICN
caching placement schemes have been proposed
in the literature that rely on different metrics and
factors [13]. In the following, we present the most
popular ICN schemes categorized based on the
caching location and used metrics. Table 1 presents a summary of these schemes along with their
characteristics and technical issues.
Multi Node-Based Caching: A multi nodebased caching scheme consists of caching content in different locations in the network. Hence, it
increases content distribution and availability; however, it may also increase content redundancy.
Leave Copy Everywhere (LCE): In LCE, all
intermediate nodes involved in the content delivery path store a copy of the data in their content-stores. Thus, future requests can be satisfied
by the nearest content-store which improves
both bandwidth utilization and enhances content access. However, due to this trivial decision
structure by nodes, content-stores may reach the
capacity quickly due to the redundant replicas
of data. This will eventually decrease the content
diversity in the network.
Leave Copy with Probability (LCProb): LCProb
is a randomized version of LCE where in-path
IEEE Network • Accepted for Publication
Authorized licensed use limited to: City, University of London. Downloaded on July 14,2020 at 04:57:43 UTC from IEEE Xplore. Restrictions apply.
2
This article has been accepted for inclusion in a future issue of this magazine. Content is final as presented, with the exception of pagination.
Caching Scheme
Purpose
Decision
Basis
Cache
Content
Redundancy Dissemination
Issues
Multi Node-based Caching
Leave Copy
Everywhere (LCE)
• Increase hit ratio.
• Reduce content retrieval
delay.
No
High
Fast
• Increased cache redundancy.
• Waste of memory utilization.
Leave Copy with
Probability (LCProb)
• Reduce content redundancy.
• Enhance content diversity.
Hop count
Medium
Medium
• Use of hop count may not lead to best path.
Consumer
(CC)
• Place content one-hop from
the consumer.
One hop
Medium
Fast
• Increased cache redundancy if consumers
are connected to different routers.
• Decreased cache utilization at contentstore due to large number of eviction.
Caching
Single Node-based Caching
Leave Copy
(LCD)
Down
• Reduce content redundancy.
• Enhance content delivery.
No
Low
Slow
• Massive caching operation.
• Overhead the bandwidth utilization.
Move Copy
(MCD)
Down
• Enhance content diversity.
• Place content closer to
consumers.
Cache hits
Low
Fast
• Selecting which content to cache is a
challenging task.
• Large number of eviction operations at the
edge node.
Edge Caching (EC)
• Place content at the edge
node.
• Provide fast content access.
Edge
Low
Fast
• Limited cache capacities of the edge node.
• A lot of content adding/eviction operations.
BetweenessCentrality (BTW)
• Use of highest betweennesscentrality parameter.
• Place content at the middle
to satisfy large number of
requests.
Betweenness
parameter
Low
Medium
• Load at the content-store if number of hops
are equal.
• Worse resource exploitation due to the use
of betweenness.
TABLE 1. Summary of content caching placement strategies.
intermediate nodes cache the content using the
caching probability of 1/(hop count). This strategy
reduces cache redundancy.
Consumer Caching (CC): In the CC strategy, the requested content must be cached only
one-hop from the consumer’s point of view. The
replica node can be an edge node or any of the
consumer’s next-hop.
Single Node-Based Caching Policies: In single
node-based caching policies, only one content-store
is selected to cache the content. The node selection is very important since it may rely on different
metrics such as the consumer’s location.
Leave Copy Down (LCD): In LCD, the content is cached only one-hop away from the original producer. Thus, the cache hit ratio will be
increased and the node will effectively utilize the
cache space. However, in case of caching popular content, all requests should be forwarded
close to the provider which will incur a large network delay.
Move Copy Down (MCD): The basic idea of
MCD is that whenever a cache hit occurs in a
node, a copy of the served content is cached one
level down toward the requester and removed
from the current content-store. This technique will
minimize the content redundancy in the network,
and move the content closer to consumers.
Edge Caching (EC): Similar to LCD, the EC strategy caches the content at the edge of the network.
The edge node can be considered an on-path or
even off-path node (dedicated edge server).
Betweeness-Centrality (BTW): This caching
scheme depends on the betweenness-centrality
parameter that must be calculated at each node.
Betweenness-centrality indicates the number of
3
times that said node is in the content delivery path
between two nodes. The node within the path
with the highest betweenness-centrality parameter
is selected as a replica node.
Content Replacement Policies
Another important aspect of in-network caching
is the content replacement in CS. If the node’s CS
is full and new popular content has arrived, the
node has to cache the new popular content and
evict another content (according to the underlying replacement policy) to keep the room [4,
14]. Following are the most widely used caching
replacement policies.
First in First Out (FIFO): According to the
FIFO strategy, the content that is received first is
the first to be evicted and replaced with the newly
received content. In doing so, the oldest cached
content is evicted from the CS regardless of its
popularity.
Least Frequently Used (LFU): In LFU, the caching plane maintains a counter for each cached
content to track how many times the said content is served. In the eviction process, the content
with the minimum value (less requested) will be
removed and replaced with the newly received
content.
Least Recently Used (LRU): The LRU strategy
aims to ensure that the popular content must be
stored in the cache as long as possible. Thus, the
content that has not been requested for a long
time is evicted from the CS and replaced with the
new content.
Time to Live (TTL): As its name indicates, the
TTL strategy consists of assigning a lifetime to
each cached content and when that time expires,
IEEE Network • Accepted for Publication
Authorized licensed use limited to: City, University of London. Downloaded on July 14,2020 at 04:57:43 UTC from IEEE Xplore. Restrictions apply.
This article has been accepted for inclusion in a future issue of this magazine. Content is final as presented, with the exception of pagination.
the content is evicted automatically regardless of
its popularity. The biggest challenge of the TTL
strategy is how to determine the appropriate expiration time.
Overall, there is no clear answer to the efficiency of any cache replacement policy. Evicting
any content has an impact on users regardless of
its popularity. Indeed, the definition of content
popularity is still fuzzy.
P1
PDPU: Proposed Flexible
Cache Management Mechanism
In this section, we discuss our proposed cache
management mechanism for ICN in detail. Our
proposed scheme is referred to as Push Down
popular, Push Up less-popular (PDPU). PDPU
aims at selecting the most optimal and nearest
cache placement node to all requesters in a fully
distributed manner. Our proposed scheme is particularly applicable in IoT applications where the
requested content by IoT devices is pushed down
toward the edge of the network only if it is popular. Similarly, the generated content by IoT sensors
and actuators is pushed down toward consumers
in a fully distributed manner and based on its popularity metrics.
In the following, we discuss the content popularity and the push operations on the content
depending on the considered parameters. Furthermore, we also elaborate the collaborative
one-hop cache notification that is essential for the
flexible cache management.
P2
PD
R1
R2
PD
R3
C2
R9
R5
R4
R6
R7
R10
R11
PU
R13
R8
R12
C1
Content Popularity
Instead of dividing the content strictly into two
major classes, popular and non-popular content,
we define a weight function r(d) that takes two
metrics as input, that is, content access frequency
(fr) and content freshness (fs) to decide the content popularity level.
r(d) = (a  fr) + (1 – a)  fs
where fs is a Boolean variable that indicates the
content’s freshness. If the received content is
fresher than the current copy stored in the CS,
then f s = 1, otherwise f s = 0. f r indicates how
many times the content has been requested from
the content-store.
Push Operations
PUPD includes two caching operations.
Push-Down (PD): Whenever the cached content popularity reaches a pre-defined threshold
based on r(d), the requested content is pushed
down only one-hop from the interface where the
interest was received, and removed from the current CS. Only the direct intermediate neighbor
node stores the said content. By pushing down
the content, we end up placing the popular (frequently asked and fresh) content closer to the
requesting nodes.
Push-Up (PU): The fact that popular content
is pushed down the network because of the PD
operation and taking the caching memory size
into consideration, the unpopular content must
be removed from the CS, while the less-popular
can be cached in the core network. To ensure a
balance between the frequently used and less-fre-
FIGURE 2. PDPU Cache Flow Example.
quently used content, we propose that the content is pushed up one-hop before evicting it from
the current CS only if it has a worthy popularity
value (r(d) ≥ qm).
The reason for the PD operation is to move
the most popular content closer to consumers in
a fully distributed manner. The aim is to serve the
maximum number of users in a short time, while
the main reason for the PU operation is to distribute the less-popular content in the core network
more efficiently rather than removing it.
Figure 2 illustrates an example of using both
PD and PU operations. We note that the content will be pushed down whenever a new cache
hit occurs. However, this may affect the network overhead, especially in case we have large
amount of popular content. To overcome this
issue, we suggest that the content will be pushed
down only if its popularity r(d) reaches a pre-defined threshold (q c), until reaching an optimal
position that may serve all the requesting nodes.
When a node has multiple interfaces and receives
demands from all of them, the node pushes down
the content from the interface that receives more
demands (e.g., demands ((q p)) > 80 percent).
Otherwise, the content is cached locally at the
said node to serve all interfaces.
Assuming an example (e.g., Fig. 2) where
nodes connected to R13 request the popular
content C1, the content is pushed down all
the way until it reaches R13 which is the optimal location and near to CS (from R13 nodes’
IEEE Network • Accepted for Publication
Authorized licensed use limited to: City, University of London. Downloaded on July 14,2020 at 04:57:43 UTC from IEEE Xplore. Restrictions apply.
4
This article has been accepted for inclusion in a future issue of this magazine. Content is final as presented, with the exception of pagination.
2
CS: {c1, c2}
FIB: {c3, c4, c5, c6}
CS: {c3, c4}
FIB: {c1, c2}
{c1, c2}
1
{c7, c8}
3
4
CS: {c7, c8}
FIB: {c5, c6}
{c5, c6}
CS: {c5, c6}
FIB: {c1, c2, c7, c8}
FIGURE 3. Cache notification example.
point of view). However, in the case of content requested from different sub-/networks,
for example, both consumers in R9 and R13
request content C2 at the same time. Pushing
down C2 to both R10 and R9 is not feasible and
may increase the duplicated cached content.
Even though if it is pushed down to R9, demands
from R13 need to be forwarded once again to
the original producer which kills the purpose of
in-network caching and reduces the applicability
of the PDPU algorithm. Hence, PDPU selects
R5 as the optimal place that can satisfy all the
demands from both branches.
Another important point that must be highlighted is when content is evicted and the PU
operation is triggered, the operation is executed
repeatedly until the content is pushed to the original producer, then it will be removed from the
content-store.
In the following, we introduce a collaborative
caching mechanism to enhance content distribution and cache hit in the ICN network.
Collaborative ICN One-Hop Cache Notification
Knowing that cached content at a local node cannot be advertised via the routing protocol, we
design a new mechanism, namely collaborative
one-hop cache notification, to maximize the benefits of in-network caching, and deliver the content from the nearest CS instead of forwarding
the request upstream. This notification message is
based on the NNCP protocol [15]. The new message is referred to as cache notification in which
the message packet carries only the name prefix
of the local cached data as well as their TTL values. The notification message is sent out to all
neighbor nodes. A neighbor node after receiving
the notification message, adds the received content names into its FIB tables with the received
interface name and the TTL value.
In PDPU, the content caching decision can
be applied on a per-traffic-class basis. Thus, the
content is cached in the optimal place from the
overall network perspective. The collaboration of
neighbor content-stores through the notification
mechanism helps to build a partial view of different cached content in the neighborhood. Hence,
it contributes to the efficiency of the used cache
strategy by increasing the probability to serve content from the nearby content-stores even if they
are not in the communication path.
5
Figure 3 illustrates an example of using the
cache notification mechanism. In the simple
mode, whenever new data is added to the content-store, a notification message is sent out. However, this mode will generate a storm of packets
that may incur a huge overhead. Thus, we propose to use the content popularity function (r(d))
to advertise only the popular content in a periodic manner. Hence, we reduce the number of
packets and consequently the network overhead.
As shown in the Fig. 3, node N1 creates a new
notification message to inform both neighbors
(N2 and N3) about contents (c1 and c2). Similarly, N2 replies with the content (c3 and c4), and
N3 with (c5 and c6). We can also notice that N1
cannot advertise (c5 and c6) to N2 because they
do not reside in its local CS. In addition, the TTL
value is also sent with the name prefix to remove
the entry from the FIB tables to keep them fresh
and clean.
Performance Evaluation
We implemented the proposed cache management scheme on top of ndnSIM. We generated
large-scale network typologies using the Python
networkx library. Consumers send requests at a
rate of 10 interests/sec. The network has 100
unique contents. Each CS can cache up to 10
packets. The threshold values of qp, qc, qm are 80,
50, and 45 percent, respectively. The objective
is to evaluate the efficiency and scalability of the
PUPD. We consider the following evaluation metrics: network delay, hop reduction ratio, cache
hit ratio, and the overall cache utilization. Moreover, we also compare the proposed scheme with
other existing strategies including LCE, LCD, EC,
and CC.
Average Network Delay
We denote the average network delay by the
average time duration to satisfy all requests (interests) issued by all the requesting nodes.
In Fig. 4a, we observe that NO CACHE has the
largest delay because all interests must be satisfied by the original producer, While LCD is below
the NO CACHE due to the fact that it caches the
content only one-hop after the producer. EC/CC
has the smallest network delay as the content is
cached closer to consumers (at only one hop
distance), while the network delay in LCE varies,
i.e., sometimes it is equal to EC/CC and sometimes larger. This can be justified due the fact that
all nodes cache the content, including the edge
node of the network. Furthermore, due to changes in the content-stores, demands may be satisfied
far away from the edge. Finally, PDPU starts with
a large network delay as the content is cached
and pushed down hop-by-hop from the producer
toward the consumers. However, we can notice
that the decrease in delay is closer (sometimes
similar) to EC/CC. This convergence is due to the
fact that the popular content is pushed down to
the optimal place.
Average Hop Reduction Ratio
The average hop reduction ratio represents the
number of hops that should be traversed to fetch
the content from the content-store(s) instead of
the original content producer. The ratio is calculated as the number of hops from consumers to
IEEE Network • Accepted for Publication
Authorized licensed use limited to: City, University of London. Downloaded on July 14,2020 at 04:57:43 UTC from IEEE Xplore. Restrictions apply.
This article has been accepted for inclusion in a future issue of this magazine. Content is final as presented, with the exception of pagination.
0.06
0.8
0.9
0.055
0.8
0.7
0.7
0.04
0.035
0.03
0.025
0.02
0.01
1
2
3
4
5
6
Simulation Time (s)
(a)
7
8
0.6
0.5
0.4
0.5
0.4
0.3
0.2
LCE
LCD
EC/CC
PDPU
NO CAHE
0.015
0.6
Cache Hit Ratio
0.045
Hop Reduction Ratio
Average Network Delay (s)
0.05
0.3
LCE
LCD
EC/CC
PDPU
0.2
9
10
1
2
3
4
5
6
Simulation Time (s)
(b)
7
8
LCE
LCD
EC/CC
PDPU
0.1
0
9
10
1
2
3
4
5
6
Simulation Time (s)
(c)
7
8
9
10
FIGURE 4. Performance evaluation: a) average network delay; b) hop reduction ratio; c) cache hit ratio.
content-stores over the number of hops from the
consumers to the original producer.
Figure 4b represents the results of average
hop reduction ratio. From the figure, we can see
that LCD has the smallest ratio as the content is
placed one-hop away from the original producer. However, EC/CC has a better ratio since the
edge node(s) (one-hop from the consumer) are
selected. Similarly, the ratio of LCE is close to EC/
CC because the edge node is also selected as a
content-store. However, we can notice that LCE
may not overlap with EC/CC as the content is
always evicted and interests may be satisfied by
other content-stores. Finally, PDPU pushes down
the popular content in a hop-by-hop fashion, the
hop ratio starts with an average value as the content is closer to the original producer and then
converges to the edge network after multiple
push operations.
Average Cache Hit Ratio
The cache hit ratio is calculated as the total number of cache hits in the network to the sum of
cache hits and cache misses. In the simulation,
we calculated the average cache hit ratio for all
nodes over all the received interests.
In Fig. 4c, we show the performance of the
cache hit ratio. Although LCE caches each traversed content, it has the lowest cache hit ratio
as compared to other strategies. This is due to
the non-cooperative nature of LCE that leads to
caching every content regardless of its popularity. However, EC/CC and LCD involve only one
intermediate content-store in the communication
path. Thus, we notice that their ratio is overlapping. Finally, PDPU starts with a lower ratio and
increases by time. This increase is due to the
push-down operation. After pushing down the
popular content, PDPU produces the highest ratio
by serving the popular content from the optimal
content-store(s).
Average Cache Utilization
The cache utilization refers to the number of
cached content in the whole network for a
request. In the simulation, we calculate the average cache utilization for all the requested content.
Figure 5 shows the average cache utilization
in terms of simulation time and the number of
unique names in the content-stores. We notice
FIGURE 5. Average cache utilization evaluation.
that LCE has a larger cache utilization because all
nodes are caching the same content (duplicated
copies) which means the diversity of cached data
is very small. However, in LCD and EC/CC only
one node caches the content, hence the cache
utilization is small even if the number of unique
content increases, while in PDPU, for each pushdown operation, only one intermediate node is
involved to cache content. In some cases, based
on content popularity, the content can be pushed
down to multiple nodes. Thus, the cache utilization is normally larger than LCD/EC/CC but smaller than LCE.
Conclusion
In-network caching is a salient feature of ICN and
it aims to dissociate the content from its original provider. It provides multiple copies of the
content in the network, reduces the overhead at
the provider side, avoids a single point of failure,
improves content retrieval, and reduces network
delay and latency. Although the integration of
ICN on top of IoT promises to enhance IoT applications and data dissemination, the cache place-
IEEE Network • Accepted for Publication
Authorized licensed use limited to: City, University of London. Downloaded on July 14,2020 at 04:57:43 UTC from IEEE Xplore. Restrictions apply.
6
This article has been accepted for inclusion in a future issue of this magazine. Content is final as presented, with the exception of pagination.
We proposed a hybrid cache placement scheme wherein we designed a hybrid cache model with a
distributed architecture. The proposed scheme aimed at selecting the optimal placement of content in
the content-store by pushing down the popular content toward the edge of the network and keeping
the less-popular content at the core of the network.
ment and replacement strategies remain open
challenges. In this article, we proposed a hybrid
cache placement scheme wherein we designed
a hybrid cache model with a distributed architecture. The proposed scheme aimed at selecting the
optimal placement of content in the content-store
by pushing down the popular content toward the
edge of the network and keeping the less-popular
content at the core of the network. Simulation
results showed that the proposed scheme is efficient, achieves the set objectives and outperforms
the existing mechanisms.
References
[1] G. Xylomenos et al., “A Survey of Information-Centric Networking Research,” IEEE Commun. Surveys & Tutorials, vol.
16, no. 2, 2014, pp. 1024–49.
[2] B. Nour et al., “A Unified Hybrid Information-Centric Naming Scheme for IoT Applications,” Computer Commun., vol.
150, Nov 2019, pp. 103–14.
[3] B. Nour et al., “Security and Privacy Challenges in Information Centric Wireless IoT Networks,” IEEE Security & Privacy,
vol. 18, no. 2, 2020, pp. 35–45.
[4] I. U. Din et al., “Caching in Information-Centric Networking:
Strategies, Challenges, and Future Research Directions,”
IEEE Commun. Surveys & Tutorials, vol. 20, no. 2, 2018, pp.
1443–74.
[5] L. Zhang et al., “Named Data Networking (NDN) Project,”
Technical Report NDN-0001, Xerox Palo Alto Research
Center-PARC, 2010.
[6] I. Yaqoob et al., “Internet of Things Architecture: Recent
Advances, Taxonomy, Requirements, and Open Challenges,” IEEE Wireless Commun., vol. 24, no. 3, 2017, pp. 10–16.
[7] B. Nour et al., “A Survey of Internet of Things Communication using ICN: A Use Case Perspective,” Computer Commun., vol. 142–43, June 2019, pp. 95–123.
[8] M. Amadeo et al., “Information-Centric Networking for the
Internet of Things: Challenges and Opportunities,” IEEE Network, vol. 30, no. 2, 2016, pp. 92–100.
[9] B. Nour et al., “Internet of Things Mobility over Information-Centric/Named-Data Networking,” IEEE Internet Computing, vol. 24, no. 1, 2020, pp. 14–24.
[10] H. Khelifi et al., “A QoS-Aware Cache Replacement Policy
for Vehicular Named Data Networks,” Proc. IEEE Global
Commun. Conf. (GLOBECOM), IEEE, 2019, pp. 1–6.
[11] B. Nour et al., “NCP: A Near ICN Cache Placement
Scheme for IoT-based Traffic Class,” Proc. IEEE Global Commun. Conf. (IEEE GLOBECOM), 2018.
7
[12] M. Zhang et al., “A Survey of Caching Mechanisms in Information-Centric Networking,” IEEE Commun. Surveys & Tutorials, vol. 17, no. 3, 2015, pp. 1473–99.
[13] I. Abdullahi et al., “Survey on Caching Approaches in Information Centric Networking,” J. Network and Computer
Applications, vol. 56, 2015, pp. 48–59.
[14] S. Ostrovskaya et al., “Towards Multi-Metric Cache
Replacement Policies in Vehicular Named Data Networks,”
IEEE Annual Int’l. Symposium on Personal, Indoor and Mobile
Radio Communications (PIMRC), Sep. 2018, pp. 1–7.
[15] B. Nour et al., “NNCP: A Named Data Network Control
Protocol for IoT Applications,” IEEE Conf. Standards Commun. Networking (CSCN), 2018, pp. 1–6.
Biographies
B oubakr N our [GS’17] (n.boubakr@bit.edu.cn) is currently
pursuing a Ph.D. degree in computer science and technology
from Beijing Institute of Technology, Beijing, China. His research
interests include next-generation networking and Internet. He
is the recipient of the Best Paper Award at IEEE GLOBECOM
(2018), and the Excellent Student Award at the Beijing Institute
of Technology in 2016, 2017, and 2018 consecutively.
Hakima Khelifi [GS’17] (hakima@bit.edu.cn) is currently pursuing a Ph.D. degree in information and communication engineering from Beijing Institute of Technology, Beijing, China. Her
current research interest includes next-generation networking
and Internet and vehicular ad hoc networks. She received the
Best Paper Award at IEEE GLOBECOM in 2018, and the Excellent Student Award at the Beijing Institute of Technology in
2017–18 and 2018–19.
Hassine Moungla [M’08] (hassine.moungla@parisdescartes.fr)
is an associate professor at the University of Paris Descartes and
a member of the Paris Descartes Computer Science Laboratory
(LIPADE) since 2008. He was a researcher with INRIA until
2008 and a research fellow with CNRS-LIPN Laboratory, Paris
Nord University until 2007. His research interests are in the field
of wireless area body networking, WSNs, middleware for 5G
and sensor networks. He serves on the editorial board of several
conferences.
Rasheed Hussain [S’09, M’15, SM’19] (r.hussain@innopolis.ru) is
an associate professor and the Director of the Institute of Information Security and Cyber-Physical Systems, Innopolis Univer-sity, Innopolis, Russia. He is also the Director of the Networks
and Blockchain Lab at Innopolis University. His research interests include information, cyber, and network security, privacy,
vehicular networks, vehicular clouds, vehicular social networking, applied cryptography, Internet of Things, content-centric
networking, cloud computing, blockchain, API security, and
machine learning in cybersecurity.
N adra G uizani (nadraguizani07@gmail.com) is an assistant
professor at the School of Electrical Engineering & Computer
Science at Washington State University, USA. She received her
Ph.D. in 2020 from Purdue University, USA. Her research interests include: machine learning, mobile networking, large data
analysis, and prediction techniques. She is an active member of
both the Women in Engineering program and the Computing
Research Association (RSA).
IEEE Network • Accepted for Publication
Authorized licensed use limited to: City, University of London. Downloaded on July 14,2020 at 04:57:43 UTC from IEEE Xplore. Restrictions apply.