This paper introduces a Content Delivery Network as a Service (CDNaaS) platform that allows dynamic deployment and life-cycle management of virtual Content Delivery Network (CDN) slices running across multiple administrative cloud domains. The CDN slice consists of four Virtual Network Function (VNF) types, namely virtual transcoders, virtual streamers, virtual caches, and a CDN-slice-specific Coordinator for the management of the slice resources across the involved cloud domains. To create an efficient CDN slice, the optimal placement of its composing VNFs using adequate amount of virtual resources for each VNF is of vital importance. In this vein, this paper devises mechanisms for allocating an appropriate set of VNFs for each CDN slice to meet its performance requirements and minimize as much as possible the incurred cost in terms of allocated virtual resources. A mathematical model is developed to evaluate the performance of the proposed mechanisms. We first formulate the VNF placement problem as two Linear Integer problem models, aiming at minimizing the cost and maximizing the Quality of Experience (QoE) of the virtual streaming service. By applying the bargaining game theory, we ensure an optimal trade-off solution between the cost efficiency and QoE. Extensive simulations are conducted to evaluate the effectiveness of the proposed models in achieving their design objectives and encouraging results are obtained.

We present an architecture for the provision of video Content Delivery Network (CDN) functionality as a service over a multi-domain cloud. We introduce the concept of a CDN slice, that is, a CDN service instance which is created upon a content provider's request, is autonomously managed, and spans multiple potentially heterogeneous edge cloud infrastructures. Our design is tailored to a 5G mobile network context, building on its inherent programmability, management flexibility, and the availability of cloud resources at the mobile edge level, thus close to end users. We exploit Network Functions Virtualization (NFV) and Multi-access Edge Computing (MEC) technologies, proposing a system which is aligned with the recent NFV and MEC standards. To deliver a Quality-of-Experience (QoE) optimized video service, we derive empirical models of video QoE as a function of service workload, which, coupled with multi-level service monitoring, drive our slice resource allocation and elastic management mechanisms. These management schemes feature autonomic compute resource scaling, and on-the-fly transcoding to adapt video bit-rate to the current network conditions. Their effectiveness is demonstrated via testbed experiments.

This article proposes a novel chunk-based caching scheme known as the Progressive Popularity-Aware Caching Scheme (PPCS) to improve content availability and eliminate the cache redundancy issue of Information-Centric Networking (ICN). Particularly, the proposal considers both entire-object caching and partial-progressive caching for popular and non-popular content objects, respectively. In the case that the content is not popular enough, PPCS first caches initial chunks of the content at the edge node and then progressively continues caching subsequent chunks at upstream Content Nodes (CNs) along the delivery path over time, according to the content popularity and each CN position. Therefore, PPCS efficiently avoids wasting cache space for storing on-path content duplicates and improves cache diversity by allowing no more than one replica of a specified content to be cached. To enable a complete ICN caching solution for communication networks, we also propose an autonomous replacement policy to optimize the cache utilization by maximizing the utility of each CN from caching content items. By simulation, we show that PPCS, utilizing edge-computing for the joint optimization of caching decision and replacement policies, considerably outperforms relevant existing ICN caching strategies in terms of latency (number of hops), cache redundancy, and content availability (hit rate), especially when the CN’s cache size is small.