# Design and Implementation of Integrated ICN and CDN as a Video Streaming Service

Chengkai Yan, Quang Ngoc Nguyen, Ilias Benkacem, Daisuke Okabe, Akihiro Nakao, Toshitaka Tsuda, Cutifa Safitri, Tarik Taleb, Takuro Sato

<figure><img src="image_1.png" /></figure>

## ► To cite this version:

Chengkai Yan, Quang Ngoc Nguyen, Ilias Benkacem, Daisuke Okabe, Akihiro Nakao, et al.. Design and Implementation of Integrated ICN and CDN as a Video Streaming Service. 17th International Conference on Wired/Wireless Internet Communication (WWIC), Jun 2019, Bologna, Italy. pp.194-206, 10.1007/978-3-030-30523-9_16. hal-02881749

HAL Id: hal-02881749

https://inria.hal.science/hal-02881749v1

Submitted on 26 Jun 2020

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
Design and Implementation of Integrated ICN and CDN
as a Video Streaming Service

Chengkai Yan<sup>1</sup>, Quang Ngoc Nguyen<sup>*1 [0000-0002-0941-7318]</sup>, Ilias Benkacem<sup>2</sup>,
Daisuke Okabe<sup>3</sup>, Akihiro Nakao<sup>4</sup>, Toshitaka Tsuda<sup>1</sup>, Cutifa Safitri<sup>5</sup>,
Tarik Taleb<sup>2</sup>, and Takuro Sato<sup>1</sup>

¹ Department of Communications and Computer Eng., Waseda University, Tokyo, Japan

² Department of Communications and Networking, Aalto University, Espoo, Finland

³ IoT & Cloud Services Business Division, Hitachi Ltd., Tokyo, Japan

⁴The University of Tokyo, Bunkyo, Tokyo, Japan

⁵ MJIIT, Universiti Teknologi Malaysia, Kuala Lumpur, Malaysia

Corresponding author*: quang.nguyen@aoni.waseda.jp

**Abstract.** In this research, we leverage the emerging concept of network slicing to enable the end-to-end integrated Information-Centric Networking (ICN) and Content Delivery Network (CDN) for 5G networking infrastructure. While CDN is deployed to cache content at the optimal server corresponding to the content and geographical location, this paper focuses on verifying the efficiency of ICN slice for regional content distribution. Specifically, the ICN slice can be established by the regional Orchestrator by following the current NFV/SDN standard. Then, the slice stitching process will be performed to interconnect two slices after their establishments via the Orchestrator. We also implement an OpenStack-based virtual node which supports both IP and ICN protocols and acts as the ICN-Gateway. The joint-testbed evaluations conducted between Japan side (ICN slice) and Europe side (CDN slice) show that the deployment of ICN Gateway and the proposed Node ID-based ICN naming structure can improve network performance and avoid network congestion.

**Keywords:** Information-Centric Networking (ICN), CDN (Content Delivery Network), network slicing, ICN/CDN, Video streaming, NFV/SDN.

# 1 Introduction

Nowadays, to match the huge demand for content distribution, we need a new network paradigm shift from IP-based services into information-based services. In this way, we can transfer information in a wide range of services efficiently, especially in the case of High-definition video transmission with high bitrate/speed requirement. In fact, video content has become a major part of the total Internet traffic, and mobile/wireless data traffic is a notable trend for content accesses in the future. According to Cisco's report, IP video traffic occupied 75 percent of the whole Internet in 2017, and this number will increase to 82 percent by 2022 in which the mobile devices will carry 44 percent of the total IP data traffic [1]. Thus, ensuring mobile user's
VoD (Video on Demand) experience is a key to realize efficient content the distribution model for the Internet.

In this context, ICN (Information-Centric Networking) [2, 3] was proposed as a promising future network approach since 2005. The key features of ICN include in-network caching and using named data instead of IP addresses for forwarding and routing content. However, ICN still has implementation issues because all the content nodes in ICN need to have the memory storage for content caching then make them consume more power compared to the IP routers [4, 5]. Also, the default caching mechanism in ICN produces high cache redundancy by wasting cache space for storing on-path content duplicates as analyzed in our prior work [6, 7].

Currently, many video service providers have selected CDN (Content Delivery Network) as their solution for serving the vast video traffic. The idea of CDN is placing suitable dedicated caches as distributed servers at the edge of various network domains or geographical regions to reduce network load and response time. However, considering the high cost of the cache servers and the video resources, CDN still has the feasibility issue for deployment.

Thus, in this paper, we have proposed to integrate CDN and ICN as a 5G network slice for efficient video streaming service which will be detailed in the next sections.

# 2 Related Work

In this section, we introduce the major concepts that are related to our proposal.

## 2.1 Content-Centric Networking (CCN)

Content-Centric Networking (CCN) [2] is a notable ICN platform that enables users to obtain desired content through its name instead of its location as defined in the existing IP-based Internet architecture. CCN is also implemented using ICN routers with caching function rather than IP-routers to realize efficient content dissemination.

In CCN, there are two types of the packet which are Interest and Data packets. Interests consist of a content name, which is requested by the consumer. Data packets carry content data and act as response for content requests, i.e., Interests. The data transmission unit in CCN is chunk, i.e., a content is split into a number of equally sized chunks.

For the content distribution process, firstly, Interests will be sent by the consumer. Then, the Interests will be broadcasted throughout the whole network. This step can be regarded as a searching strategy: Once a user sends an Interest, it will be sent to the nearest node to minimize the transmission time. Besides, users who are in the same area may express the Interests for the same content so that they can get the desired content from the suitable intermediate ICN nodes without the need of downloading it from the content provider (server).

For the data retrieval process, the content name prefix will be searched in the cache memory of the CCN routers, called Content Store (CS). If Interest matches the prefix, data will be returned to the consumer via the corresponding face (network interface). Otherwise, Interest will continue finding the content in Pending Interest Table (PIT) [2]. If the required content exists, content data is sent back by the reverse path of Interest
and a new entry of Interest will be added to PIT. If the content still can not be found, that information will also be recorded in PIT. Then, Interest will be forwarded according to Forwarding Information Base (FIB) for the forwarding procedure [2, 8].

Besides the name-based forwarding strategy, another key feature of CCN is in-network caching. Different from TCP/IP design, CCN node has its cache memory so that it can store downloaded contents dynamically. In other words, once the content has been downloaded, it will be cached by the CCN node. Hence, the total content downloading time and E2E (End to End) hop count can be reduced.

## 2.2 Content Delivery Network (CDN)

Recently, CDN has been widely implemented to serve the content-based services, represented by the well-known CDN operators, e.g., Netflix, Akamai. CDN deploys edge servers which contain contents from the original content producers/servers. In this way, the data traffic of the original server can be split to multiple mirror cache servers, which leads to relieving the burden of the source server. Additionally, based on users' geo-metric information (such as IP addresses), the DNS (Domain Name System) server can identify which edge server is the nearest one to users. Thus, it can allocate the most appropriate server to the user and the downloading time on the user side can be reduced considerably. Hence, the users' QoE (Quality of Experience) can be improved as well. Also, CDN users from different ISPs (Internet Service Provider) and regions can gain similar bitrate experience [9].

However, CDN still has its disadvantages. Firstly, due to the high cost of deploying CDN mirror edge servers, CDN users are requested to pay an additional fee for the premier services. Next, the content updating process (i.e., pushing new video contents to the edge servers) takes time and may not be suitable for every scenario. In general, CDN is primarily used for VoD (Video on Demand) or downloading services. However, in some specific scenarios, users do not need all the cached contents then some of the valuable cache memory is being wasted. Thirdly, though deploying CDN servers can reduce and separate data traffic from the core server, bottleneck sometimes can still happen.

Specifically, when users' requests become huge in one specific area, the data traffic between users and this area's CDN edge cache servers can cause the network bottleneck. In order to prevent this situation, the service providers and CDN operator should increase the number of available CDN caches, which might lead to a higher cost.

## 2.3 SDN/NFV (Software-Defined Networking/Network Functions Virtualization)

Due to the increasingly diverse need from the user side, ISPs are currently in need of adaptive services to meet users' various demands. However, different from allocating a single service, customizing multiple types of service via physical network resource configuration is challenging. For example, nowadays, FHD (Full High-Definition) or even UHD (Ultra High-Definition) video streaming service and VoIP (Voice over IP) service are among the most popular applications of network service, but they have different optimized network resource configurations. Particularly, HD/UHD video
streaming service requires high bandwidth and throughput while VoIP service requires
a stable network environment and low-latency. Moreover, it takes time and a high cost
to set up and tune each network service. The introduction of NFV (Network Functions
Virtualization) and SDN (Software-Defined Networking) in recent years then aims to
satisfy the strong demand of "dynamic network configuration".

NFV uses virtualization technology to split network applications in a simple and
adaptive manner. A general NFV architecture usually includes VNFs (Virtualized
Network Functions), Hardware resources, Virtualization Layer, NFVI (NFV
Infrastructure), NFV Management and Orchestration (NFVM and NFVO). Specifically,
NFVI is the key to manage the hardware resources and change the physical hardware
into virtualization resources pool so that the computing components can be managed
flexibly and conveniently. The VNFs can install and provide service
applications. Also, the VNFM and NFVO are responsible for managing and
orchestrating the NFV's whole resources and processes [10].

As NFV offers the solution for making physical network resource virtual, SDN is
the other technology needed for link virtualization. The most crucial feature of SDN is
that it separates the network connection into control-plane and data-plane. By
separating the two planes, network control becomes more convenient and flexible since
control-plane requires flexibility whereas data-plane requires low-latency. For instance,
the processes such as switching routing protocols and generating routing table can be
implemented on one control-plane. To complete the separation, a protocol named
OpenFlow would be used [11].

## 2.4 Network Slicing

Network Slicing is a virtualization technology based on NFV/SDN. It enables running
multiple logical networks on one common shared-physical network infrastructure to
maximize the flexibility and maintainability. Besides, the network resources are split
dynamically so that each logical network's parameter such as capacity, bandwidth, and
delay can be customized corresponding to the user requests and network status.

Network slicing plays an essential role as a key concept in the upcoming 5G network
to realize various high-speed network applications, e.g., IoT (Internet of Things) and
8K streaming services [12]. Particularly, the ISPs could manage and customize each
network slice simply and comfortably by defining each network service as one dynamic
network slice and separate them logically [13].

In this research, we apply the emerging concepts of ICN, CDN, and SDN/NFV
technologies to realize a network slicing design for efficient content delivery over
different multiple geographical locations.

# 3 System Design

In this section, we introduce the concept and mechanism of the proposed CDN/ICN
content delivery system.
<figure><img src="image_3.png" /><figcaption>Fig. 1. ICN/CDN System Configuration</figcaption></figure>

**3.1 The Proposed ICN/CDN System**

In this research, we combine CDN with ICN to enable an efficient contents delivery
network system with low congestion rate. Besides, to meet the future mobile network's
needs, we have also proposed using our system as one 5G service slice in the context
of the project "5G! Pagoda", a collaborative Europe-Japan research project for
softwarized 5G network evolutions [14].

The benefits of integrating ICN and CDN are three-fold as follows:

Firstly, using CDN and ICN can drastically reduce the congestion ratio of the whole
network. Particularly, as aforementioned in Section 2, CDN can reduce the data traffic
of the core/original server by deploying multiple edge mirror cache servers in various
regions. However, when the number of users becomes large enough in one region, the
congestion would occur at the edge servers. Therefore, by adding ICN nodes linked to
the CDN edge servers, we aim to substantially diminish data traffics of CDN edge cache
servers, thanks to the ICN's in-network caching feature [15].

The second benefit is increasing the users’ QoE (delay time), especially for
contents with high popularity level. By using CDN’s cache server for dynamic and
optimized content allocations, the download time for the requested content can be
reduced considerably [16]. Specifically, this improvement is realized by the efficient
retrieval process from the CDN slice to the ICN slice via the appropriate CDN cache
and the ICN Gateway.

Additionally, as ICN is a potential future network design at the initial deployment
stage and CDN has been a successful content-based business model, by combining
CDN and ICN, we can take advantage the merits of both networking models: CDN is
used for optimal content allocations at suitable CDN caches nearby the clients while
ICN is used for quickly distribute content to users via the ICN nodes with the built-in
dynamic in-network caching feature.
## 3.2 System Overview

To show that our ICN/CDN system can provide an efficient and realistic video delivery model in real-world, we configure the whole system across different continents. Specifically, the system has been implemented to transfer content objects (videos) published in Finland (Europe EU) to Japan (JP, Asia). In this way, we are expecting to model and realize a promising and practical video streaming system deployment, e.g., Netflix or YouTube videos.

Fig. 1 demonstrates our integrated ICN/CDN system configuration. In our design, the system includes two major parts which are CDN slice for contents provider side ("EU Side") and ICN slice for content distribution to users ("Japan Side"). Typically, on the EU region, the original CDN content server deployed at Aalto University, Finland (Aalto server) has been set up to publish video contents. Also, we assume that users will request their desired video contents from the Japan region. Thus, CDN cache mirror server and ICN nodes are deployed on the Japan side.

Since our whole work is to realize the 5G network slicing concept, each network slice is implemented based on SDN/NFV technology. It is also necessary to define a regional Orchestrator to manage every VNF instance dynamically. Typically, the EU Orchestrator is responsible for managing each instance and resource pool on the EU side while Aalto servers represent the CDN publishers/providers.

The ICN slice configuration is shown in Fig. 2 in which ICN nodes are implemented by JP Orchestrator (Hitachi Orchestrator) using CCN platform on the Japan side. Firstly, the video contents are stored in the ICN Gateway (an OpenStack based CDN/ICN edge video cache server on the Japan side). Then, we add ICN Gateway FIB entries to CCN nodes for the efficient forwarding process in ICN. Hence, the video content information from the ICN cache can be shared through the Japan domain via the CCN nodes in ICN slice. To reduce the network load and congestion, we use multiple ICN-enabled edge nodes (with transient caches and substantial lower cache storage compared to CDN caches) to separate the content traffic of the ICN Gateway from the other ICN intermediate nodes.

## 3.3 End-to-End (E2E) Content Delivery

In this part, we briefly present a complete E2E content delivery procedure of the proposed ICN/CDN system. It contains four major steps which are slice establishment, slice stitching, content request, and content delivery.

Firstly, in the "slice establishment" stage, all the CDN and ICN NFV instances are initiated and allocated virtually. During this stage, both JP and EU' Orchestrators will create and configure each instance with a suitable virtual configuration dynamically.

Then, "slice stitching" stage will be executed. After ICN and CDN instances have been established, JP Orchestrator will inform ICN Coordinator and provide the Coordinator the FIB entries of ICN Gateway so that ICN nodes can determine the suitable routing path. After the ICN nodes add the FIB entries of ICN gateway, the slice stitching process is completed.
Next, the user sends the content request, and the content delivery process will be
performed. Upon the slice stitching's completion and the video service is triggered at
the CDN slice, the user receives the table of contents which lists all of the available
video contents' "exact name" (which will be detailed in Section 3.4) with resolution,
video name, bitrate and the corresponding CDN cache from CDN coordinator. The user
then can choose which video they want to watch. When the user selects the desired
video content, the system will generate an ICN Interest to ICN Gateway to check
whether this content is already cached in ICN slice or not. If it has been cached, then
the target content will be renamed as CCN "exact name" format and sent back to the
User Equipment (UE). When the UE receives the exact content name and acknowledge
it, the content transmission can start. Otherwise, if the user selects the desired content
and the ICN Gateway does not have the content that the user asked, this Interest will be
converted as a content request to the suitable CDN server with respective content. The
CDN server then pushes the requested content to ICN Gateway. In this way, users can
receive the content in the ICN slice when the same content Interests are received again.

3.4 Naming Strategy in ICN

One key feature of ICN is that its information route is based on the content name instead
of an IP address. Specifically, each ICN content has its own unique ICN name without
the need of name resolution via the DNS (Domain Name Server) system as of the
TCP/IP architecture.

However, since in our ICN/CDN video streaming system, both ICN (CCN platform) and IP (CDN) are co-existed, the suitable way to transfer and convert the content name format from IP to CCN is worth to be considered so that UEs in Japan side can receive the desired data efficiently via the Gateway in the ICN slice [17].

Firstly, the initial content name on the CDN side consists of an article name, resolu-
tion, bitrate, and video package format. For example, on the Aalto CDN server, a *Demo*
video content is named as *"Demo-1920*\*1080-3000kbps.avi"*.

However, in CCN, since we want to let the user know which ICN node is involved
in serving a specific content, we decide to implement another naming format by adding
a "Node ID". "Node ID" represents the caching node with the requested content name
for content distribution in ICN from CDN slice. Thus, in the simplified case, the "Node
ID" will be "ICN Gateway". Besides, we add the content source with location before
"Node ID" (left-most position) in the content naming structure. As "Finland, EU"
(Aalto University) is the content publisher's location in our system design, and the CCN
name should be "/EU/Finland/Aalto-University/ICN-Gateway/Demo-1920*1080-
3000kbps.avi". By using this naming format, the user can be aware of the content trans-
mission so that they can decide whether to receive the content or not. Since the naming
format in CCN is Longest-Prefix Match (LPM) for forwarding and routing procedure,
we define the proposed CCN name structure as the content "exact name".

3.5 ICN Gateway

As shown in Fig. 1 and Fig. 2, between the ICN slice and the CDN slice, we have
deployed an additional OpenStack-based node and named it as "ICN-Gateway". The
ICN-Gateway enables both CCN and TCP/IP protocol so that the video content from the CDN cache server can be cached inside the CCN's repository. From ICN-Gateway, cached contents would be stored at ICN intermediate nodes then transfer to users for minimizing the latency of subsequent content accesses.

Meanwhile, ICN-Gateway takes responsibility for converting content name from CDN naming format into the proposed CCN's "exact name".

# 4 System Evaluations

## 4.1 FLARE-based ICN Nodes

Regarding the proposed ICN/CDN system implementation, we build the joint test-bed based E2E content delivery at Waseda University in which the virtual content nodes image and configuration setting are installed in deeply programmable nodes, namely FLARE, developed by the University of Tokyo. We select FLARE as it enables an Open Deeply Programmable Switch/Network Node Architecture to verify the merits of the proposal over multi-domain test-bed with multi-core processors toward 5G slicing [18]. FLARE also realizes resource isolation with lightweight control plane and data plane programmability. We then implemented ICN Based Virtualization nodes on FLARE, and the hardware configuration of FLARE is shown in Table 1. Specifically, we use Docker as the container technology to implement ICN nodes' virtualization over FLAREs.

Also, since Hitachi. Ltd. acts as the Orchestrator of the Japan domain (Fig. 1), ICN nodes can be established and managed dynamically so that the ICN slice follows the network slicing standardization [19].

## 4.2 The Proposed System Configuration

Note that in this research, we focus on the ICN Slice design for content distribution when the content objects are already stored at the ICN Gateway from the CDN Slice, i.e., suppose that Optimal VNFs Placement in CDN Slicing over Multi-domain is already performed. Then, this paper is different from our prior work in the same research theme which presented the overall integrated ICN/CDN system design [16].

For the experiment evaluation, we have set up an ICN slice configuration as shown in Fig. 3. Particularly, at first, an OpenStack based ICN-Gateway caches the test video content. Then, upon receiving the message from Orchestrator (Hitachi Orchestrator), the ICN coordinator can receive the FIB entry of ICN-Gateway. By using this information, FLARE-ICN Node 1 can be set up and make a connection with ICN-Gateway in CCN protocol (slice stitching procedure). Next, two ICN nodes are connected, and finally, on the UE side, UE 1 is connected with ICN Node 1 while UE 2 makes a connection with ICN Node 2 via the CCN protocol. We use this system configuration as the evaluation scenario model to verify the benefit of using CCN nodes with in-network caching feature so that the video contents with high popularity in a geographical domain can be transmitted to the user side efficiently with minimized response time [20].
<table><caption>**Table 1.** FLARE's detailed configuration.</caption><thead><tr><td>Parameter</td><td>Value</td></tr></thead><tbody><tr><td>Spec</td><td>72 core EZ-Chip Network processor</td></tr><tr><td>SFP+</td><td>2 ports, up to 128GB memory / 1TB SSD</td></tr><tr><td>GbE</td><td>24 ports and 10 GbE</td></tr><tr><td>Power</td><td>Redundant Power supply</td></tr></tbody></table>

## 4.3 Test Scenarios

After the slice stitching procedure is completed by the Orchestrator at the Japan side via information exchanges from Gateway at ICN slice, we perform the test scenarios using the above testbed configuration. In particular, we conduct four different test scenarios to verify the efficiency of the proposed ICN/CDN system for content distribution in which the content delivery is conducted twice for each scenario as follows:

* **Scenario 1:** Firstly, the content request is sent from UE1. Then, for the second time, the content request (for the same content) is also sent by UE1.

* **Scenario 2:** First content request is sent from UE2, and a second-time request is from UE1 for the same content.

* **Scenario 3:** The first-time request is from UE1, and then UE2 will send Interest for the same content.

* **Scenario 4:** Both requests are sent by UE2.

It should be noted that the test content file in each Scenario has the same size (either 1MB or 10MB). Then, we have evaluated ICN slice performance by measuring downloading time, E2E hops count, throughput, and Round-Trip Time (RTT) [21] which will be detailed in the next subsection.

## 4.4 The Integrated ICN/CDN System Performance Evaluations and Discussion

The four above network metrics are evaluated as follows:

**Downloading Time.** Downloading time means spending time since a user sends the first content Interest until the requested file's last chunk is transmitted to the user. Shorter download time refers to a higher transmission rate. As shown in Fig. 4, we have measured downloading time using the 1MB and 10MB sized file and in both cases, the

<figure><img src="image_4.png" /><figcaption>**Fig. 2.** ICN Slice Configuration</figcaption></figure>

<figure><img src="image_5.png" /><figcaption>**Fig. 3.** FLARE-based Testbed Configuration</figcaption></figure>
<figure><img src="image_6.png" /><figcaption>Fig. 4. Download time</figcaption></figure>

<figure><img src="image_7.png" /></figure>

<figure><img src="image_8.png" /><figcaption>Fig. 5. End-to-End Hop Counts</figcaption></figure>

<figure><img src="image_9.png" /><figcaption>Fig. 6. Round-Trip Time</figcaption></figure>

second time request's download time is much smaller than the first time. Thus, as long as the content has been cached by ICN nodes once (i.e., the requested content is stored in ICN slice), the buffering time for streaming service on the user side can be reduced considerably. As a result, QoE can be ensured, especially in the case of popular content.

**E2E Hop Counts.** Similarly, when measuring the number of hop counts between UEs and the content source, we realize that the second time request's hops are always less than that of the first time (Fig. 5). The reason is that thanks to the in-network caching feature in ICN, for all the four test scenarios, the contents will be cached at the nearest ICN nodes after the first request.

**Round-trip Time (RTT).** RTT measures the period since a packet is sent until it is responded. As shown in Fig. 6, RTT gets smaller after the first Interest when we test a content file in CCN's default chunk size (4KB). As the requested content is stored at the nearest nodes (ICN node 1 or ICN node 2) after the first request, the subsequent requests for the same content become smoother, i.e., a reduced RTT shows better QoE on the user side.

**Throughput.** Throughput is a key performance of the network, and the same tendency can be realized when measuring throughput in both cases of 1 MB and 10 MB
<figure><img src="image_10.png" /><figcaption>Fig. 7. Throughput</figcaption></figure>

test contents (Fig. 7). Specifically, in scenario 2 and scenario 3, the second time requests always get higher throughput compared to the first time. However, in scenario 1 and scenario 4, the throughput performance is decreased. The reason is that since our UEs are also equipped with CCN protocol, UEs will cache content into their repository with the built-in in-network caching feature as long as they retrieve the content once. This result explains why when users send the same Interest as the first time, they do not have a high throughput via their network interfaces. This deployment then also leads to less heavy data traffics for a stable network with low congestion rate.

Overall, the above scenarios show that our proposed system can improve the network performance efficiently right after a requested content is stored in the ICN slice.

# 5 Conclusion

In this paper, we have proposed, designed, implemented, and evaluated the combined ICN/CDN architecture as a video streaming service. The joint-testbed evaluations between Japan and Europe show that our approach can reduce the download time effectively, especially when transmitting contents with high popularity. This realizes a potential and feasible network design for efficient video streaming service by leveraging SDN/NFV technologies and combining the benefits of both ICN and CDN for video content distribution.

The concept and design of function chaining design for optimal VNF allocation in network slicing of the integrated ICN/CDN will be the focus of our future work.

# Acknowledgment

This research was partly funded by 5G! Pagoda project, which is funded by European Commission's H2020 program under grant agreement No.723172 and by the SCOPE project of MIC (Ministry of Internal Affairs and Communications) of Japan. This work was also supported by Waseda University Grant for Special Research Projects grant number 2019C-174.
References

1. Cisco Visual Networking Index: Forecast and. Trends, 2017–2022. [Available Online]

2. V. Jacobson, et al. "Networking named content" In Proc. of ACM CoNEXT'09, Dec.2009.

3. G. Xylomenos et al., "A Survey of Information-Centric Networking Research," IEEE Commun. Surveys & Tutorials, 2013, pp. 1–26.

4. Q. N. Nguyen et al., "A Context-Aware Green Information-Centric Networking Model for Future Wireless Communications," in *IEEE Access*, vol. 6, pp. 22804-22816, 2018.

5. Q. N. Nguyen, M. Arifuzzaman, T. Miyamoto and S. Takuro, "An Optimal Information Centric Networking Model for the Future Green Network," 2015 IEEE Twelfth International Symposium on Autonomous Decentralized Systems, Taichung, 2015, pp. 272-277.

6. M. Arifuzzaman, Y. Keping, Q. N. Nguyen and S. Takuro, "Locating the content in the locality: ICN caching and routing strategy revisited," 2015 European Conference on Networks and Communications (EuCNC), Paris, 2015, pp. 423-428.

7. Nguyen, Q.N. et al., "PPCS: A Progressive Popularity-Aware Caching Scheme for Edge-Based Cache Redundancy Avoidance in Information-Centric Networks". Sensors 2019, 694.

8. Y. N. Rohmah, D. W. Sudiharto and A. Herutomo, "The performance comparison of forwarding mechanism between IPv4 and Named Data Networking (NDN). Case study: A node compromised by the prefix hijack," 2017 3rd International Conference on Science in Information Technology (ICSITech), Bandung, 2017, pp. 302-306.

9. G. Zhang, W. Liu, X. Hei and W. Cheng, "Unreeling Xunlei Kankan: Understanding Hybrid CDN-P2P Video-on-Demand Streaming," in *IEEE Transactions on Multimedia*, vol. 17, no. 2, pp. 229-242, Feb. 2015.

10. Network Functions Virtualisation (NFV); Management and Orchestration; Report on Architectural Options, ETSI Group Specification NFVIFA 009, Jul. 2017.

11. D. Kreutz, et al., "Software-Defined Networking: A Comprehensive Survey," in Proceedings of the IEEE, vol. 103, no. 1, pp. 14-76, Jan. 2015".

12. T. Taleb, et al., "PERMIT: Network Slicing for Personalized 5G Mobile Telecommunications," in *IEEE Communications Magazine*, vol. 55, no. 5, pp. 88-93, May 2017.

13. J. Zhang, X. Zhang and W. Wang, "Cache-Enabled Software Defined Heterogeneous Networks for Green and Flexible 5G Networks," in *IEEE Access*, vol. 4, pp. 3591-3604, 2016.

14. 5G! Pagoda Project, [Available Online] https://5g-pagoda.aalto.fi/

15. X. Wang, et al. "Cache in the air: exploiting content caching and delivery techniques for 5G systems," in *IEEE Communications Magazine*, vol. 52, no. 2, pp. 131-139, February 2014.

16. I. Benkacem, M. Bagaa, T. Taleb, Q.N. Nguyen, T. Tsuda, and T. Sato, "Integrated ICN and CDN Slice as a Service," in *IEEE Globecom'18*, Abu Dhabi, UAE, Dec. 2018.

17. K. Kanai et al., "Proactive Content Caching for Mobile Video Utilizing Transportation Systems and Evaluation Through Field Experiments," in *IEEE Journal on Selected Areas in Communications*, vol. 34, no. 8, pp. 2102-2114, Aug. 2016.

18. A. Nakao, et al., "End-to-end network slicing for 5G Mobile networks", Journal of Information Processing, Vol 25, pp153-163, 2017.

19. M Arumaithurai et al., "Exploiting ICN for flexible management of software-defined networks," in ACM-ICN '14 Proceedings of the 1st ACM Conference on Information-Centric Networking, pp. 107-116, Paris, France — September 24 - 26, 2014.

20. Jianfeng Guan, Wei Quan, Changqiao Xu and Hongke Zhang, "The comparison and performance analysis of CCN under mobile environments," 2014 IEEE 3rd International Conference on Cloud Computing and Intelligence Systems, Shenzhen, 2014, pp. 292-296.

21. A. Kerrouche, et al., "AC-QoS-FS: Ant colony based QoS-aware forwarding strategy for routing in Named Data Networking," 2017 IEEE ICC, Paris, 2017, pp. 1-6.