Cooperative Content Caching in MEC-Enabled Heterogeneous Cellular Networks

Multimedia content delivery via the cellular infrastructure increases fast due to the very high volumes of mobile video traffic generated by the billions of end devices populating the mobile data network. A critical mass of mobile video content requests refers to the consumption of the same popular video content, which is consumed by different end terminals spanning small geographical regions. Such content requests place a great burden on the backhaul of content-agnostic cellular networks, which fail to exploit the correlation of video requests to decongest their backhaul links. This creates redundant retransmissions while fetching the same video content from a central server to the network edge, using the bandwidth-limited backhaul at peak-time periods. With the integration of multi-access edge computing (MEC) capabilities in 5G mobile cellular networks, mobile network operators can place popular video content closer to the network edge at off-peak time periods, predicting user requests exhibiting a high correlation for a given time interval over smaller geographical regions. In this paper, we investigate popular content placement in multi-tier heterogeneous cellular networks where the edge network infrastructure can cooperate to create content delivery (and placement) clusters to effectively serve correlated video requests. To this end, we model the cooperative content placement problem using the multiple knapsack problem (MKP) formulation and present an exact (optimal) bound-and-bound strategy to solve it. The performance of the proposed strategy is evaluated in-depth using extensive system-level simulations and is compared against that of other state-of-the-art algorithms. Valuable design guidelines and key performance trade-offs are discussed, paving the way towards cluster-based cooperative caching in MEC-enabled cellular network setups.


I. INTRODUCTION
The emergence of new technologies, such as the Internet of things (IoT), machine to machine communications (M2M), e-health, and vehicular communications has pushed the cellular traffic much higher than anticipated [1]. Before the outbreak of the COVID-19 pandemic in 2020, recent reports [2] on cellular network traffic predicted a five-fold increase of the monthly mobile traffic, from 33 exabytes in 2019 to 164 exabytes by 2025, exhibiting an annual growth of 31%. Mobile data traffic is dominated by mobile video content, which in 2020 accounts for 63% of the total traffic, while it is predicted to exceed 76% by 2025, exhibiting an The associate editor coordinating the review of this manuscript and approving it for publication was Giuseppe Araniti .
annual growth rate of 30% [2]. The ever-increasing mobile video traffic stems from the fast growth of high-bandwidth demanding multimedia services, such as video on demand (VoD), augmented reality, immersive media formats and the multi-billions of mobile broadband subscriptions. On top of that, online streaming is extensively used to support the daily activities and working routine of humans around the globe, especially after the outbreak of the COVID-19 pandemic, which has accelerated the extensive use of online video streaming services and teleworking.
Although mobile cellular networks are being upgraded to accommodate the offered mobile data traffic load, e.g., through the deployment of new generation fronthaul and backhaul technologies, the exponential increase of mobile video traffic still brings the utilization of existing backhaul VOLUME 9, 2021 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ links to their capacity limits, questioning the scalability of existing systems in light of the ever-increasing demand for mobile video content delivery. Backhaul congestion is aggravated by factors, such as the size of contents, the overall number of video consumers and the characteristics governing video consumption (e.g., screen size, quality of experience -QoE -requirements, video resolution). Mobile video traffic is dominated by multiple requests of the same popular video content, creating overlapping end-to-end video content delivery chains, starting from the edge network terminals and ending to the servers hosting the requested content in the far Internet. Popular video segments are redundantly re-transmitted from the central content server (residing in the far Internet) to the end user equipment (UE) (residing at the network edge) creating unnecessary utilization of intermediate network resources, especially in heterogeneous cellular networks (HCN) with multiple network tiers and high deployment density [3]. This problem will be further exacerbated in the fifth generation (5G) of mobile cellular networks, where low latency requirements of less than 1ms are targeted for specific service types co-utilizing the wireless medium [4]. To alleviate redundancy upon popular content transmission throughout the cellular infrastructure and meet the high-end performance targets set for 5G and Beyond mobile data networks, the utilization of edge network caching has been proposed as a cost-effective capacity-boosting network-layer solution [5], [6].
Edge network caching consists of the edge content placement and the edge content delivery phases. Edge content placement refers to the process by which the storage of edge network nodes is filled with popular content to reduce the delay and backhaul overheads of fetching popular content from central servers outside the network service domain to the network edge. Edge content delivery refers to the process by which the cached content is delivered to the content consumers (edge users), utilizing multiple wireless links and radio access technologies (RATs). The performance of cache-enabled mobile cellular networks strongly depends on the optimization techniques used to place popular video contents in the edge network and on the mixture of technologies used to deliver the respective content to the end terminals [7]- [9].
Edge content placement and delivery can utilize storage resources available in different types of network elements, including macrocell base stations (MBS), small base stations (SBS), femtocell base stations (FBS) and UEs. Edge content placement and delivery can utilize multi-access edge computing (MEC) capabilities at the network edge, a technology that has been long-viewed as the cornerstone for seamless delivery of personalized video content. For example, MEC nodes can [10] i) predict content popularity to locally store popular video chunks in the near area of mobile users and offload the radio access network (RAN) during on-peak periods (reducing thus the user-perceived latency), ii) employ local transcoding on high-resolution videos to match the screen resolution of mobile terminals (thus, enhancing the user-perceived rate), and iii) move relevant content and context closer to the end user (increasing thus the user-perceived 5G service availability) [11]. In the sequel, we will refer to the cache-enabled (infrastructure) nodes, whose main role is to cache popular video content and relay it to the end users without transcoding, as mobile helpers (MHs).
In this paper, we are concerned with popular content placement at the network edge and focus on the challenging scenario where the edge network nodes of the HCN, which form cache-enabled MEC clusters, coordinate the placement of popular video contents and cooperate to deliver the respective content to the edge users within their coverage. On the one hand, node coordination refers to the employment of joint decision making towards an optimized placement of popular video contents over the entire MEC cluster (i.e. creating a joint virtual storage pool of individual caches) without allowing content partitioning (i.e. the entire content is stored per node). On the other hand, cooperation in content delivery assumes that if a requested content is found in the cache of a node belonging to the MEC cluster, within which the user request has been recorded, then the MEC cluster nodes shall cooperate to relay the content to the serving node of the user (i.e. the node where the original request has been made by the user). Accordingly, a cache hit is considered to take place if i) the content request of the user is made to a node belonging to a tagged MEC cluster c and ii) any cache-enabled node belonging to c has cached the requested content.
Without focusing on how the requested content is relayed from a MEC node hosting the content to the MEC node serving the user request, in the sequel, we formulate the MEC-enabled cooperative content placement problem and present an exact algorithm that enables joint content placement into the individual caches of the MEC-enabled cluster nodes. To this end, we use the cache hit probability (CHP) as the optimization metric at the cluster level subject to a set of constraints, which includes the placement of entire video files per cluster with no repetition, no content partitioning, and the limited cache sizes of the nodes.
The remainder of the paper is organized as follows. Section II summarizes related works in the area and highlights the key differences of our modeling and optimization approach in light of current state-of-the-art. Section III introduces the system description and the problem formulation for cooperative cluster-based content caching in MEC-enabled HCNs. The proposed content placement strategy is presented in section IV. In section V, we evaluate the performance of the proposed content placement strategy using extensive system-level simulations and provide detailed comparisons with other state-of-the-art algorithms. Section VI contains our conclusions.

II. RELATED WORK AND MOTIVATION
Existing works on modeling and performance analysis of edge network caching may be categorized into two broad classes: non-cooperative, which assume that each MH acts autonomously and selects the content to be placed into its cache using its own logic, and cooperative, which assumes centrally planned content placement and delivery across multiple network nodes that cooperate to this end. Assuming equal file size for popular contents and random request distribution, the authors in [12], [13] have shown that cooperative caching enables significant improvements on network performance due to the enhanced utilization of edge computing and storage resources. Under the same set of assumptions, a lower download latency and better utilization of storage resources has also been reported in [3]. In our previous work in [14] we have formulated the non-cooperative content placement problem for a single MH using a 0/1 single knapsack problem formulation given a generic file popularity and size distribution for popular video contents.
The authors in [12] have formulated the joint content placement and delivery, showing that it is an NP-hard problem. Accordingly, they have relaxed the original nested dual problem to a mixed integer non-linear program (MINLP) and employed a branch-and-bound method to enable MHs decide on their own the content to be placed in their cache. Although the respective formulation and methodology used to solve the problem is promising, the proposed system-wide centralized optimization of the joint content placement and delivery phases faces significant scalability challenges due to the centralized aggregation of radio network information from all nodes in the system and the required scaling of the proposed solution to a very large number of nodes in the HCN. The authors in [3] have decoupled the original joint content placement and delivery problem by using i) integer linear programming for solving the content placement problem and ii) employing unbalanced assignments for solving the content delivery problem.
Content placement is typically formulated as a constrained problem, which is modeled using different mathematical frameworks. Depending on the proposed placement model, different algorithms are used to solve the proposed formulation. The survey work in [15] reviews the most widely used modeling methods including, among others, game-theoretic, stochastic, and predictive approaches. The authors in [16] have used multiple-choice knapsack problems to model the cooperative content placement problem in large instances. The emphasis was given on caching layered videos using a fully polynomial time approximation (FPTA) algorithm. The authors in [17] have modeled content placement as a reward maximization problem and solved it by reducing to solvable linear programs. Similarly, the authors in [18] have used mixed integer programming to model the content placement problem and employed greedy algorithms to solve it. In [3], the authors have used linear integer programming to model the content placement problem and applied Lagrangian relaxation with hierarchical prime-dual decomposition to decouple its structure into two-levels, enabling solutions using the sub-gradient method.
Greedy and heuristic algorithms are computationally feasible in large-scale networks but exhibit sub-optimal performance in the general case. In [19], the authors describe a cooperative multi-tier caching system that is decomposed into a series of independent knapsack sub-problems, which are solved by using greedy methods. Focusing on adaptive streaming, the authors in [20] have used a polynomial time greedy method to solve a series of knapsack problems, in order to cache different versions of a video at the network edge. Authors in [21], have modeled the content placement problem using stochastic approach and have applied a fully polynomial time approximation method where a random set of contents is cached to the network edge, and the placement probabilities within a tier are considered to be the same. In [22], the authors employ stochastic geometry under fixed cache size and bandwidth constraints, assuming a greedy method to solve the proposed content placement problem.
The authors in [23] have used uncoded caching for the content placement phase (file partitioning without transcoding) and index coding for the content delivery phase, by broadcasting the coded messages. The Lyapunov function is employed in [24] to allow hybrid cloud and edge content caching using greedy and heuristic content placement algorithms. In [25], content placement is modeled as a multiple knapsack problem and dynamic programming (DP) is used to solve the uncoded caching case. Nevertheless, the profit maximization problem still depends on approximations of scaling, before the DP is applied. Additional effort is required to deal with the inhomogeneous content popularity over large geographical areas, the limited storage and network capacity as well as the heterogeneous characteristics of the cache-enabled edge network nodes.
Different from the vast majority of existing approaches, which typically formulate the problem of network-wide content placement given a content popularity distribution, in this work we focus on the emerging scenario where the mobile network operator (MNO) can assign the heterogeneous edge network nodes of the HCN to MEC clusters of different sizes and capabilities, e.g. different number of infrastructure nodes per MEC cluster, different mixture of MEC node types and cache sizes. MEC integration into the Radio Access Network (RAN) will create an overlay layer of MEC service areas, enabling MNOs not only to cope with the different video popularities met across neighbor geographical regions but also to adapt MEC service coverage to the actual topology and capabilities of HCN nodes.
In light of the forthcoming MEC/RAN integration, current literature includes a noteworthy amount of MEC clustering techniques that incorporate different optimization criteria, such as minimizing end-to-end delay of MEC services [26], reducing traffic congestion within the MEC cluster [27], enhancing MEC service coverage [28], or offloading core network traffic to the edge MEC nodes [29]. Given the rich literature in the area, in this work, we choose not to focus on how to form a MEC cluster. Instead, we focus on how to optimize content placement within a given MEC cluster of known size (in terms of number of nodes) assuming potentially different cache sizes across the MEC nodes. To this end, VOLUME 9, 2021 we consider that our strategy is used after the employment of a MEC clustering technique. A key requirement is that MEC clustering is performed such that intra-cluster content exchange is performed at a low transmission cost, forming a robust content delivery path between i) the MEC node serving the video request directly to the end user and ii) the MEC node that hosts the requested video content within the MEC cluster.
Without loss of generality, we consider that content placement and intra-cluster content delivery is centrally coordinated by a MEC cluster head. We further consider that intra-cluster content delivery is performed in response to the video requests, whereas content placement is performed on an epoch-by-epoch basis. We define an epoch as the time interval within which the list of popular video files is valid for the entire MEC service area. The size and popularity of popular files are assumed to be known to the MEC cluster head and remain fixed for a given epoch. Current literature includes a large volume of techniques for identifying popular video contents and estimating their popularity distribution within a target area [30].
Different from current state-of-the-art, we formulate and solve a 0/1 multiple knapsack problem (ZOMKP) that integrates the following two practical constraints i) MEC nodes store complete files only (no file partitioning) and ii) only one MEC node is allowed to store a given file within the same MEC cluster (no file repetition). Both these constraints result in a mathematically more involved problem but are of high practical interest in realistic MEC-enabled setups as explained below. Firstly, adding/removing cached segments of a given file from the cache of multiple MEC nodes comes with increased communication and cache monitoring overheads, whereas the released cache may not be fully utilized (or be sufficient) to cache a new video file. Also, distributed (coded) caching in different nodes of the MEC cluster requires perfect tracking of cached segments and sophisticated multi-source transmission schemes to be implemented within the MEC cluster. Secondly, even though redundant caching of the same file at different MEC nodes increases the availability of popular contents within the same MEC cluster, reducing the intra-cluster transmission cost given a cache hit, also degrades the probability of having a cache hit event in the MEC cluster due to the under-utilization of the available storage resources. Accordingly, the two requirements of no file partitioning and no file repetition are in line with MEC-enabled service provisioning, which primarily aims to leverage edge network resources and avoid the utilization of end-to-end links to the far Internet through the backhaul network.
Different from the vast majority of existing works, which typically relax the original problem formulation constraints to strike a good performance trade-off between cache hit efficiency and computation time, in our work we present an exact (optimal) content placement strategy that employs a highly-effective bound-and-bound methodology that explores the full-state space of the problem in a smart fashion. Compared to traditional branch-and-bound methodologies, the proposed bound-and-bound strategy exploits both an upper and a lower performance bound to quickly eliminate sub-optimal solution branches without going deeper into the evaluation of sub-optimal solution branches. Using extensive system level simulations we validate that under realistic MEC system setups, the proposed bound-and-bound content placement strategy is computationally feasible. The main contributions of this paper are summarized as follows: • We investigate how content placement can be formulated and optimized under the emerging MEC/RAN integration scenario, where the MNO can bundle edge network, computation and storage resources to form joint MEC/RAN service clusters (areas). The formation of MEC service areas shall enable the MNOs to better adapt to i) the local spatiotemporal file popularity in smaller geographical areas and ii) the actual topology and capabilities of HCN nodes.
• We provide a ZOMKP formulation of the cooperative content placement problem within a given MEC cluster, under practical constraints with regard to the heterogeneity of cache sizes of cluster nodes, the no-repetition of popular video files within the same cluster, the non-uniformity of content popularity and the un-coded placement of video files (no file repetition is allowed within the same MEC cluster).
• We propose an exact bound-and-bound search strategy to solve the proposed ZOMKP formulation. A lower bound (LB) is obtained by fixing sequentially files to the caches of MHs using the 0/1 single knapsack problem (ZOSKP) formulation in [14]. An upper bound (UB) is obtained by assuming a virtual aggregate cache pool of size equal to the sum of individual cache sizes of the MHs and employing the ZOSKP solution in [14]. The LB is used to avoid exploration of content placement solution branches exhibiting sub-optimal performance, whereas the UB is used to mitigate unnecessary computations towards the exploration of additional solutions.
• We provide extensive system-level simulations to evaluate the performance of the proposed strategy in MEC-enabled multi-tier HCN, while we also compare its performance to that of the widely-used greedy and random content placement strategies. Moreover, we highlight the key performance trade-offs governing the content placement phase in MEC clusters, while we also derive valuable design guidelines and discuss best practices for MEC cluster formation and content placement in multi-tier MEC-enabled HCNs.

A. SYSTEM DESCRIPTION
We focus on the downlink direction of a multi-tier MEC-enabled HCN, where each tier consists of HCN nodes of similar networking capabilities. We consider that the MNO employs a cluster formation algorithm to group a heterogeneous set of cache-enabled HCN nodes into MEC clusters that will carry out the edge network caching process (both content placement and delivery). A cache-enabled MEC cluster can be composed by HCN nodes belonging to different network tiers. In Fig. 1(a), we provide an illustrative example of a three-tier system model instance, where UE-1 is out of coverage of SBS-2. Without loss of generality, for each MEC-enabled cluster, we consider that the content placement is centrally planned by a cluster head (e.g. an MBS). Cache-enabled nodes belonging to the same MEC cluster may have different cache sizes (i.e. storage capacity), while they are considered to follow the instructions of the MEC cluster head to fill their cache with the allocated content during off-peak periods. We focus on the content placement process for a given time period, which we term as the cache epoch. For a tagged cache epoch, we consider that the cluster head concludes on a target list of popular video files with known popularity and file size. The popularity is evaluated on a per epoch and cluster basis, while it can match the user request ratio on a per cluster basis for the given popular video file. MEC cluster heads are considered to deploy their own policy to infer the list of popular files and the popularity distribution governing the list within their coverage area, potentially encompassing information from the MNO's core network (e.g., using techniques similar to those in [30]).
At any time, end users are considered to associate with a serving HCN node, following the network discovery and attachment protocols of the Radio Access Technology employed by the HCN. If the serving HCN is not a cache-enabled node belonging to a MEC cluster, it serves the video request as usual (i.e., end-to-end connection to the content delivery server at the Internet). However, if the serving HCN node is a MEC node, it first examines whether the requested video can be found in its local cache. If a local cache hit takes place, the serving MEC node will serve the video request without establishing an end-to-end connection to the content server. If not, the serving MEC node will subsequently seek the requested video content within the MEC cluster it belongs to, e.g., by querying the cluster head, or by utilizing a cache map available to all MHs belonging to the same MEC cluster.
If the content is found in the cache of another MH belonging to the same MEC cluster (cluster cache hit), in-cluster content delivery methods shall be deployed to relay the requested video content to the serving HCN node and, finally, to the end user. Provided that files are not partitioned and that a single copy of a popular file can be cached within a given MEC cluster, it follows that in-cluster content delivery comes down to the implementation of a direct, or a multi-hop link between the serving MEC node and the MEC node (MH) hosting the content, depending on the technologies available in the MEC cluster. If the file cannot be found in the cache of any cluster node (including the serving HCN node) then the serving HCN node shall establish an end-to-end connection to the content delivery server, hosting the requested video content. Assuming that intra-cluster MEC content delivery requires significantly lower delay and network overheads compared to an end-to-end connection to the content delivery server in the far Internet, in the sequel, we consider a cache hit event to take place if i) the serving HCN node is part of a MEC cluster and ii) one of the MHs forming the respective MEC cluster has a copy of the requested video content in its cache. Note that the proposed problem formulation and solution apply also when the user requests are served by multiple MEC nodes, i.e. the CHP performance of VOLUME 9, 2021 the cluster is not affected by the methods used for content delivery.
Let us now focus on the content placement process of a given cache epoch and a tagged cache-enabled MEC cluster of interest. Let N denote the number of nodes in the tagged MEC cluster and let L n denote the cache size (in bits) of the n-th node belonging to the MEC cluster with n ∈ At the beginning of each cache epoch, the MEC cluster head is assumed to be aware of the list of popular files M, the size of popular files in S, the popularity values in P as well as the number N and cache size values L n of all mobile helpers in n ∈ {1, . . . , N }. Using those parameters as an input, the cluster head implements its content placement algorithm to decide on the popular files that should be cached in the buffers of all N cluster nodes belonging to its cache-enabled MEC cluster. For a given epoch, the content placement strategy should take into consideration that i) the number of MHs in the cluster is fixed to N , ii) the cache size available per cluster node n ∈ {1, .., N } is fixed and known (L n ), iii) the size and popularity of files in M are fixed and known (using sets S and P), iv) no repetition of popular files is allowed across the caches of individual MHs forming the MEC cluster, v) cluster nodes are considered capable to relay content from another cluster node to another to server user requests, and vi) file partitioning is not allowed (i.e. cluster nodes cache entire files and not video chunks).
Assuming that the content placement procedure has concluded, let C n denote the set of cached popular files at the n th MH and C = N n=1 C n the full set of cached files in the MEC cluster, where C n ⊆ M and C ⊆ M. Given the system model constraints mentioned above, it readily follows that and that c∈C n s c ≤ L n . Accordingly, the cluster head is required to maximize the cluster cache hit probability (CHP), a metric that we define on the basis of the popularity distribution characterizing the library M as follows: Recall that the CHP is defined as the probability that a requested video content is found in the cache of any MH belonging to the MEC cluster where the original video request has been made. In the sequel, we define the index parameter x n,m to denote the realization of the event where the n-the MH of the MEC cluster has cached the popular video file f m ∈ M with n ∈ {1, . . . , N }. Accordingly, x n,m = 1 if the event f m ∈ C n holds true and x n,m = 0, otherwise. Provided that file partitioning is not allowed and that MHs belonging to the same cluster cannot cache the same popular video file, it readily follows that N n=1 x n,m ≤ 1 for 1 ≤ m ≤ |M|. Accordingly, we present the ZOMKP formulation in the context of MEC-enabled cluster-based edge content placement in HCNs.
should be adapted by the content placement strategy so as to maximize the cluster-wide CHP C under the constraints of Eqs.(2b)-(2e). Eq. (2b) formalizes the constraint that the total size of video files placed per MH cannot exceed its cache size limit. Eq. (2c) formalizes the constraint that a popular video file cannot be cached in more than one MHs belonging to the same MEC cluster (no file repetition). Eq. (2d) ensures that file partitioning is not allowed (i.e. no intermediate values are enabled). Eq. (2e) follows by construction of the file popularity (i.e. the ρ m values are probability values summing up to one for all f m ∈ M).
Note that by removing the constraint of Eq. (2e) we can allow the popularity values of ρ m (m ∈ {1, . . . , |M|}) to take arbitrary values and not be normalized as probabilities in view of a popularity distribution over the state space M. However, in such an occasion, the proposed CHP metric should be considered as a utility (reward) function rather than a probability and be revised accordingly. For easy reference, Table 1 summarizes the notation used for the main system model parameters.

IV. PROPOSED SOLUTION
The ZOMKP is an NP-hard problem [8]. In this section, we modify an exact bound-and-bound method that was originally proposed in [31] and adapt it to the context of our formulation in Eq. (2). The proposed bound-and-bound content placement strategy is a modification of a typical branch-and-bound state space exploration technique that progressively fills the cache of a tagged MH taking into consideration both an upper and a lower performance bound to avoid the evaluation of inefficient solution branches. As a branch we consider a content placement chain where i) the placement of a given number of files has been fixed to the cache of some MHs and ii) multiple options exist on fixing the remaining files to the cache of some MHs with non-full buffer. In the sequel, we consider that the MHs of the MEC cluster under scope are sorted in increasing order of their cache size, i.e., L 1 ≤ L 2 ≤ . . . ≤ L N , and that the popular videos in library |M| are sorted in decreasing order of their 'popularity per size unit', i.e., The proposed strategy calculates the upper CHP performance bound of the original problem assuming the ideal scenario where files are placed into a single knapsack of size L = N n=1 L n . This scenario corresponds to the case where all MHs of the MEC cluster form a virtual aggregate pool of their cache resources, where files can be partitioned within the underlying physical caches of MHs but only full files will be cached in the aggregate MEC cache. The aforementioned problem is equivalent to the ZOSKP for which optimal solution algorithms exist [14], [32]. A lower performance bound is also calculated by independently fixing files into the caches of MHs progressively (i.e. the MHs are filled one by one, on increasing order of cache sizes) by using an algorithm solving the individual ZOSKP formulations assuming that popular files of the previous iterations are removed from M.
Based on the lower and upper performance bounds, the proposed strategy is capable of rejecting specific solutions by i) progressively placings files into the cache of MHs, ii) calculate the corresponding upper and lower performance bounds conditioned on the aforementioned placements, and iii) rejecting solution branches that exhibit poor CHP performance through the use of a backtracking solution process. A different stack data structure is used per MH to enable effective backtracking of the partial solution and the exploration of new solution branches (including the re-calculation of upper and lower performance bounds).
In the following subsections, we explain the building blocks of the proposed bound-and-bound (BaB) content placement strategy that aims to solve the ZOMKP. Section IV-A discusses an exact content placement strategy of the ZOSKP, based on our previous work in [14]. The respective strategy is used to derive upper and lower bound for the CHP in section IV-B, where the proposed content placement strategy for the ZOMKP formulation is also presented. More details on why the proposed content placement strategy is exact and optimal can be found in [31], [32].

A. EXACT STRATEGY FOR THE 0/1 SINGLE KNAPSACK PROBLEM
Content placement to the cache of a single MH can be modeled by the widely known 0/1-Knapsack problem and optimally solved using dynamic programming (DP) [14], [32]. A DP method breaks one problem into multiple sub-problems and solves them sequentially. In [14], we have presented an exact algorithm that utilizes a two-dimensional array structure V of size (|M| + 1) x (L + 1), which is used to track the different solution branches and infer on the optimal solution to the problem. Each column of V corresponds to a 'unit size' of the available MH's cache, whereas each row of V to the evaluation of a given file f m ∈ M. The values of V [m, j] record the highest CHP value that can be attained for the sub-problem where the first m popular files are to be placed into a cache of a single MH j cache with size j units (e.g. MBs). Accordingly, the optimal CHP value is given by Apart from obtaining the optimal CHP value, a backtracking process should be also performed on V to identify the optimal content placement solution, i.e. which files should be cached per MH. Starting from V [|M| + 1, L + 1], the backtracking process skips rows (of the current column) that have the same value with V [|M|+1, L+1]. When a different value is found, the file corresponding the respective row is included in the solution and the current column is updated by shifting an equal number of columns with the size of the respective file. The process continues using the same methodology and concludes when no different CHP values can be found in V .
Algorithm 1 provides the pseudocode of the content placement strategy used to solve the ZOSKP. The algorithm uses as an input a library of popular videos M, a vector of corresponding popularities P, a vector of corresponding file sizes S and the available cache size L. The output of the algorithm is the optimal content placement for the ZOSKP problem, which we denote by * and an index vector x of size |M| that indicates whether file m is selected (x m = 1), or not (x m = 0). Steps 4-5 are used to initialize the algorithm parameters, assuming that the call X = Zeros(x 1 , . . . , x k ) initializes the k-dimensional vector X of size x 1 xx 2 . . . xx k with zeros. Steps 5-15 calculate the optimal CHP value in a content-by-content fashion, whereas steps 15-27 conclude the algorithm by backtracking the two-dimensional array V to identify the file allocation x m leading to the derived optimal CHP * .

B. EXACT STRATEGY FOR THE 0/1 MULTIPLE KNAPSACK PROBLEM
In this subsection we present an enumerative strategy where the caches of MHs are filled progressively, evaluating the VOLUME 9, 2021   MHs in an ascending order based on their available cache size (i.e. L 1 ≤ L 2 ≤ . . . ≤ L N ). In each iteration, the proposed strategy evaluates whether a popular video file m, which has not yet been assigned to a previous MH, will be cached to the current MH, or not. In each iteration, the strategy evaluates the files to be placed in the cache of MH n. Files that have been currently evaluated for MH n are stacked into a data structure D n . A two-dimensional vectorx is used to store the current (partial) solution of the ZOMKP instance, wherê x n,m = 1 if file m is (temporarily considered to be) cached in MH n andx n,m = 0, if not. When the content placement strategy evaluates MH n, the caches of MHs 1, . . . , n − 1 are assumed to be fully filled while the caches of MHs n, . . . , N will be empty.
The upper performance bound is calculated using Algorithm 2 (section IV-B1), whereas the lower performance bound by using Algorithm 3 (section IV-B2). The proposed content placement strategy is implemented by Algorithm IV-B (section), which combines the outputs of Algorithms 1-3. The calculation of both upper and lower performance bounds is based on the use of single ZOSKP implemented by Algorithm 1.

1) UPPER BOUND CALCULATION
Algorithm 2 is used to calculate the upper CHP performance bound conditioned on the placement of a given subset of popular video files from M according to the allocation vectorx.
In the sequel, we use the notation {L n } to denote the array of values taken by L n and the notation {D n } to denote the arry of values taken by the stacks D n , where n ∈ {1, . . . , N }. The allocation vectorx is a two-dimensional array of size N by |M| that indicates whether file m is allocated to the cache of the MH n, or not. At this point, it is important to note that Algorithm 2 is called in intermediate steps of the proposed bound-and-bound content placement strategy to evaluate the CHP potential of solutions branches conditioned on the placement of a subset of files according tox. However, since the proposed strategy is enabled to call Algorithm 2 when the cache of the currently evaluated MH i is not yet fully filled, the identifier i is also passed as an input to calculate the cache size remaining for the respective MH. Recall that by this step, the proposed strategy will have filled the caches of MHs 1, . . . , i − 1 and part of the i-th MHs cache. In step 4, Algorithm 2 calculates the available cache size of MHs that have not yet been examined (i.e. helpers i + 1, . . . , N ) adding the residual cache size of MH i based on the placement of files depicted in the two-dimensional vectorx. In step 5, the algorithm identifies the set of popular videos in M that have not been cached to MHs at previous steps (including the current MH i). Steps 6 and 7 filter the popularity and size of video files inM that have not yet been placed in any MH.
Accordingly, Algorithm 2 uses the set of non-cached video filesM, together with the respective sets of popularity and file sizesP andS, respectively, to deploy the ZOSKP algorithm 1 on the respective sub-problem (i.e. 0/1 allocation of files inM into a single knapsack of sizeL). In step 9, Algorithm 2 calculates the current achievable ultimate upper performance bound of the ZOMKP formulation taking into consideration the CHP following from the placement described by the allocation vectorx. To this end, step 9 adds i) the CHP obtained for the ZOSKP sub-problem with libraryM and single knapsack of sizeL to ii) the CHP following from the placement of files performed in previous steps according tox.

2) LOWER BOUND CALCULATION
The calculation of the lower bound ( L ) is based on solving N − i + 1 independent ZOSKP formulations sequentially given the allocation vectorx and the identifier of the i-the MH to which the cached is not yet fully filled. In each round, the Algorithm 3 removes from the library files that have been placed to previous MHs and a new ZOSKP sub-problem is defined. Algorithm 3 implements the aforementioned procedure to calculate a tight lower CHP performance bound conditioned on the content placement described by the allocation vectorx. The solutions obtained by the aforementioned logic are stored into a two-dimensional arrayx and are provided as an output of the algorithm. In step 4, Algorithm 3 evaluates the baseline CHP according to the content placement described byx, which refers on the allocation of files into the caches of MHs 1, . . . , i. In step 5 the algorithm identifies the set of files that have not yet been placed to previous MHs (i.e. 1, . . . , i − 1). In steps 6-9, the algorithm makes necessary initializations to run the ZOSKP algorithm for the i-th MH, by excluding files that have already been considered for MH i and are included in D i (step 6), filtering the popularity (step 7) and file size (step 8) vectors, and taking into consideration only the residual cache available at the i-the MH (step 9).

Algorithm 3: Lower CHP Bound Calculation
In steps 10-19, Algorithm 3 performs a MH-per-MH assignment of files to the caches of MHs i, . . . , N . In more detail, steps 11-12 are used to solve the ZOSKP sub-problem for the n-th MH and to add the respective part of the MEC-wide CHP to the lower bound L , steps 13-15 enable storing of the LB solution to thex vector, whereas steps 14-19 update the input parametersM,P,S andL for the next MH taking into consideration the content placement that took place during step n of the for loop.
The Initialize part sets necessary strategy parameters (steps 5-6) and evaluates the ultimate upper CHP performance bound (steps 7-8), which is derived using the optimal ZOSKP allocation (Algorithm 1) assuming the original file library M and a single knapsack of a total L = N n=1 L n (i.e. files can be segmented within the MEC cluster but as a total, the MEC cluster contains only full files). The Baseline-Placement part is responsible for calculating the lower performance bound LB and the corresponding file placement inx (step 10), given a problem instance where the MHs' caches are partially filled (ZOKMP sub-problem). The respective fixing is described by the D n stacks and the allocation vectorx, which are both adapted during the ContentPlacement part of the strategy (see below).
If the content placement solution found by the LB-MKP algorithm results in improved CHP performance ψ (step 12), then the solution is included in the final allocation vector x (steps 12 -17). Accordingly, if the CHP of the respective solution matches the ultimate upper performance bound UB , the proposed strategy concludes to avoid unnecessary computations (steps [18][19][20]. If not, the strategy continues and verifies whether the current lower and upper performance bounds match and if so, the Backtrack part of the strategy is called (steps 21-23). This step enables the strategy to improve the upper performance bound U and explore solutions with higher CHP performance gains (i.e. closer to the ultimate upper bound UB .
The ContentPlacement part of the strategy is the place where the solution derived from the LB calculation during the BaselinePlacement process is implemented by stacking the respective files into the cache of each MH sequentially. MHs are examined in ascending caching size (steps 26, 38 and 39), while the files fixed per MH are selected based on the highest available 'value per unit size' order (steps 27 and 29). Recall that by construction MHs are ordered in ascending cache size and files are ordered in descending 'value per  [30][31][32], the upper CHP performance bound is re-calculated (step 33) and if it is lower than the current CHP performance ψ (step 34), part of the solution will be backtracked using the Backtrack part of the algorithm (steps [34][35][36]. The procedure resumes after corrective measures are taken using the Backtrack logic, potentially running recursively part of the strategy again to identify a better content placement solution. The Backtrack part of the strategy is called under different occasions, including the ones that we have discussed above. The main role of Backtrack is to remove allocations from the fixed MHs' stacks D n that are shown to deteriorate the CHP performance of the conditional (partial) solution to the problem as depicted by the allocations D n (steps 44-48). To this end, Backtrack starts removing files from the MHs' cache that triggered the Backtrack call (e.g. through the Content-Placement trigger in line 36) and then evaluates if the upper bound CHP performance is improved through this action (step 49). If not, the Backtrack logic continues to remove files from the D n stacks of the MHs (steps 41, 55 and 56) until the BaselinePlacement call is triggered to take corrective measures (steps 50-52). The proposed bound-and-bound content placement strategy terminates either when a solution is shown to attain the ultimate CHP probability UB (step 20), or when no further improvements can take place on the CHP ψ attained by the current solution x (step 57).

V. NUMERICAL RESULTS
In this section, we assess the performance of the proposed content placement strategy and compare it to that of two widely used strategies: the random and the greedy content placement strategies. Different variants of the two strategies are found in current state-of-the-art, e.g. for random in [21], [36]- [38] and for greedy in [19], [20], [22], [34], [35]. For our performance comparisons, we have considered the following variants in view of the ZOMKP formulation. The random strategy arbitrarily selects content from the library M of popular contents and places it without repetition to the caches of all MHs belonging to the cluster. The greedy strategy orders video files of M in descending order based on their popularity and places them in the cache of MHs sequentially without repetition, i.e. the cache of the first MH is filled by skipping files that cannot fit, then the cache of the second MH is filled with the remaining files, etc., until no other file can fit into the cache of any MH. Similar strategies have been considered in [21] and [33], respectively. In both the random and greedy strategies, the MHs are ordered based on their available cache size in ascending order, filling the caches of MHs with smaller cache size first.
We investigate the performance of the proposed, random and greedy content placement strategies using extensive system-level simulations in MATLAB. To this end, we consider a multi-tier HCN that includes two types of cache-enabled MHs: small base stations (SBSs) and femto base stations (FBSs). Accordingly, we consider a MEC cluster of a fixed number of N 1 SBSs and N 2 FBSs. The cache size of each SBS is set according to a truncated normal distribution of mean cache size ξ 1 GBs with standard deviation σ 1 GBs. On the other hand, the cache size of each SBS is set assuming a truncated normal distribution of mean cache size ξ 2 GBs with standard deviation σ 2 GBs. Thus, for a tagged SBS MH i the cache size is given as L i = N (ξ 1 , σ 2 1 ), whereas for a tagged FBS MH j the cache size is given as L j = N (ξ 2 , σ 2 2 ) with i, j ∈ {1, . . . , N }. Accordingly, the total cache size available in the cluster is distributed as follows Regarding the library of popular files M we consider that it includes a total of |M| popular videos. The size of each video is assumed to follow an exponential distribution of mean size µ GBs (i.e. s m ∼ exp (µ) for m ∈ M). This gives us on the average a total size (of all popular videos) of E |M| m=1 s m = |M| · µ. The popularity distribution of video files in M is assumed to follow the widely-accepted Zipf distribution according to which, the popularity value ρ m of the m th most popular content in library M is given by Eq. (3), where γ ≥ 0 is the Zipf parameter (a.k.a. popularity skewness) and m ∈ {1, . . . , |M|}.
Note that as the value of γ increases, a smaller amount of videos in M exhibit high popularity and thus, the popularity is concentrated to a smaller number of videos. On the other hand, as the value of γ decreases, the popularity is distributed in more videos and thus, a larger number of videos of lower popularity are encountered. Unless differently stated, the values for the main simulation parameters discussed above are fixed as in Table 2. According to the average bit rate values recommended by Google for video uploads in YouTube [39] and the NTT-DOCOMO guideline for video delivery in mobile data networks in [40], the mean content size depends on the video codec type, the video bitrate in Mbps and the type of the application (e.g. gaming, music videoclips). In Table 3, we summarize some common YouTube video types and their respective size, whereas in Table 4 we overview the limitations adopted by major social media providers on the  upload of videos to their platforms. According to the values presented in this table, we fix the mean content size value µ to 4GB, which corresponds to an HDR (4K) YouTube video of display resolution 3840×2160 (2160p) at High Frame Rate and length of approximately 8 minutes at bit rate 66Mbps. Such types of videos currently dominate the Internet traffic. We further fix the Zipf skewness parameter to γ = 1.0, which corresponds to the scenario where 10% of video contents to account for 75% of the popularity (i.e. their popularity probabilities sum up to 0.75).

A. IMPACT OF THE MH MEAN CACHE SIZE
We begin the performance evaluation of the three content placement strategies for an increasing mean SBS cache size ξ 1 . Note that in our simulations, we have set the FBS mean cache size parameter ξ 2 to be proportional to the respective SBS mean cache size value ξ 1 as follows ξ 1 = 20 · ξ 2 ( Table 2); thus, an increase to the mean SBS cache size also increases proportionally both the FBS cache size and the total cache size available in the MEC cluster under scope (i.e. L ∼ N ξ 1 (N 1 + 20 · N 2 ), N 1 · σ 2 1 + N 2 · σ 2 2 ). In Fig. 2 we plot the cluster-wide CHP for increasing SBS cache size ξ 1 under three different mean file sizes µ. Recall that the cache size of the SBS MH i is distributed according to a normal distribution L i ∼ N (x 1 , σ 2 1 ) and that the file size of popular videos follows an exponential distribution s m ∼ exp (µ). As expected, when the library size of popular videos is fixed (M = 5000 - Table 2), an increasing cache size at the SBS MHs improves the average CHP of the cluster for all content placement strategies. The improvement of the VOLUME 9, 2021 CHP for the random strategy is linear due to the random utilization of the available cache size, whereas a fast increase is observed for the proposed and greedy strategies in low ξ 1 values, indicating that both strategies can better exploit the additional buffer available to the cluster by the SBS MHs.
For the given set of fixed system parameters and a fixed mean file size µ, the performance of the proposed and greedy strategies is similar when the mean SBS cache size ξ 1 is small (e.g. ξ 1 ≤ 50GBs). Nonetheless, the respective performance gap grows rapidly as the SBS cache size increases to higher values for all µ values under scope. The performance improvement attained by the proposed strategy can be explained as follows. The full state space of the ZOMKP can be viewed as a content placement tree, where each e2e branch is a solution instance fixing specific files to the cache of specific MHs. The number of solutions (size of the state space) can be derived by taking into consideration all potential file placements in the available cache of MHs (depth varies depending on the file and cache sizes). Solutions that involve the same sequence of (file-MH) placements share a common route in the content placement tree, i.e. they are ancestors to the same solution branch. Each content placement strategy finds its way to the solution tree according to its logic. The random strategy moves randomly from a parent tree node to an ancestor, whereas the greedy strategy always places the file with the current highest popularity until the caches of MHs are unable to fit more files.
Accordingly, the greedy placement strategy moves through the solution space by appending into the solution a file placement with the current highest popularity value, attaining a sequence of local optimums in a greedy fashion. In contrast, the proposed strategy explores the solution tree by moving in depth to assess the CHP performance of every solution branch, using upper / lower performance bounds to eliminate sub-branches (including their ancestor solutions) with sub-optimal CHP performance and backtracking the current optimal solution by moving back to the solution space tree whenever necessary. In this fashion, the proposed strategy is capable of exploring the full state space in a smart fashion, identifying the optimal content placement and avoiding unnecessary calculations.
The superior performance of the proposed strategy is also highlighted by Fig. 3 as well where, instead of the CHP, we plot the utilization of the available cache in a cluster-wide scale under different mean file size values. Observer in Fig. 3 that the proposed strategy attains a utilization close to 100% under all scenarios under scope, whereas the greedy and random strategies are shown to leave a small amount of cache resources underutilized (i.e. cluster cache utilization lower than 1). For the given set of fixed system parameters ( Table 2), Fig. 3 illustrates that the impact of the mean file size µ is negligible to the utilization of the available cluster-wide cache size, i.e., the different µ values considered in the legend result in similar performance for each strategy. Regarding the combined impact of the mean file size µ parameter and the mean SBS cache size ξ 1 , Fig. 2 illustrates that a lower mean file size µ (e.g., µ = 4GB vs. µ = 12GB) enables all strategies to attain a higher CHP, especially when the mean SBS cache size ξ 1 increases. This directly follows from the fact that for a fixed number (and size) of M, a larger cache size shall increase the probability of all strategies to make a better allocation to the caches of cluster MHs provided that a larger volume of popular video files can fit in the existing MHs' caches. Besides, this is the reason why for a lower mean file size µ = 4, the random strategy exhibits a fast increase to its performance as compared to higher mean file sizes (e.g. µ = 8, 12). Interestingly, the proposed strategy for µ = 12GB is shown to attain a similar CHP with the greedy strategy for µ = 8GB, highlighting that the proposed strategy enables an enhanced utilization of the cache capabilities available by the MHs constituting the MEC cluster even when larger files are considered.
Let us now investigate the impact of a different mixture of cache sizes across the SBS and the FBS MHs on the cluster CHP performance, assuming that the mean cache size of an SBS MH is proportional to the mean cache size of FBS MHs with ratio β, i.e. ξ 1 = βξ 2 . Fig. 4   content placement strategies increases with ξ 2 and β. In fact, for ξ 2 = 50GBs and β = 50, the available cache size in the MEC cluster is sufficient to store the entire set of video files in M, enabling all strategies to attain a CHP close to 1.
Similarly to Fig. 2, the CHP of the random strategy increases linearly with the available cache size (modeled by the ratio β in Fig. 4). However, the ratio of the CHP improvement strongly depends on the mean cache size ξ 2 assumed for the FBS MHs. For β = 0 (i.e. no SBS MHs), we observe that the random strategy performs poorly independent of the mean file size µ, whereas the proposed and greedy strategies exhibit similar performance as they are able to exploit the available cache size fitting popular files with higher popularity (e.g. for ξ 2 = 4GBs, they fit a single popular file on the average given that µ = 4). As the β parameter increases and the mean FBS cache size is higher, e.g. β > 40 and ξ 2 = 20GBs, the CHP performance of the random strategy is shown to fast close the CHP gap with the proposed and greedy strategies, indicating that random content placement can provide comparable benefits with more sophisticated strategies if the MHs have a large volume of storage resources available for content caching. This observation can be useful to MEC clusters with high storage capacity but low processing capabilities, enabling the cluster head to deploy random content placement with good CHP performance.
Nonetheless, random content placement when the MEC cluster consists of SBS MHs with low storage capacity (e.g. β < 20) performs poorly. On the contrary, both the proposed and the greedy strategies exhibit high CHP performance gains even when the available cache size at the FBS MHs is low (e.g. ξ 2 = 4GBs) and when the cache size of SBS MHs is high (e.g. β > 20). In both cases, the proposed content placement strategy outperforms the greedy strategy enabling the MEC cluster to attain 3-5% better CHP performance, especially when the total cluster size cannot support caching of a large volume of popular video files in M (i.e. CHP is lower than 1).
In Fig. 5 we investigate the interplay between increasing the mean SBS cache size under different Zipf popularity values γ . Recall that a lower γ parameter corresponds to 'spreading' the popularity to a larger number of video files in M, whereas a higher γ parameter corresponds to 'concentrating' the popularity to a smaller set of video files. Interestingly, the performance of the random strategy is shown to remain unaffected by the Zipf popularity parameter γ . This follows from the fact that, on the average, random content placement will result in caching video files with popularity summing up to the same value. Fig. 5 also illustrates that a lower Zipf popularity parameter γ (e.g. by comparing γ = 1.2 to γ = 0.4) the performance of all strategies deteriorates.
Another interesting observation is that the performance gap between the proposed and the greedy content placement strategies fast increases as the value of γ is decreased (e.g. compare γ = 0.8 and γ = 0.4). This readily follows from the fact that a lower popularity skewness γ spreads the popularity to more files leading to a large number of files with comparable popularity but different size. Provided that the greedy strategy is size-agnostic and assigns popular video files to the cache of MHs taking into consideration only the popularity of the files in M, it readily follows that popularity-based greedy content placement is unable to infer on an appropriate combination of video files to be allocated to the available cache of MHs. This is a result of the different file sizes and MH caches considered in our simulation (i.e. the respective parameters are not assumed to be fixed and equal for all files and MHs, respectively).
On the contrary, the proposed strategy is shown to better adapt to the heterogeneity of both the file sizes met in M and the cache size available to the MHs, enabling an enhanced CHP performance as compared to the greedy strategy. In particular, when the popularity is spread to a larger volume of video files (e.g. for a low popularity value γ = 0.4) and the cache size available in the different types of MHs forming the MEC cluster is more diverse (e.g. for ξ 1 = 100GBs, SBSs have 95GBs more cache available as compared to FBSs), the performance gap between the proposed and the greedy strategies largely increases. For ξ 1 = 100GBs. we observe that the respective performance gap reaches up to a 20% CHP improvement in an absolute scale and 40% improvement in a relative scale.
As a takeaway result, we conclude that the proposed bound-and-bound MKP 0/1 strategy can better exploit the available cache size of MEC clusters with higher heterogeneity, in terms of available cache size per MH, enabling the MEC cluster to attain a higher CHP performance. This performance improvement is even more evident when the popularity of video files in M is spread to a larger volume of video files (e.g. when the Zipf parameter γ is lower). Taking into consideration that the performance of the proposed and greedy strategies is comparable for a higher values of the popularity parameter γ , e.g. γ > 1.2, another interesting observation is that in such scenarios, the MEC cluster head may choose to run the greedy strategy instead of the proposed one to save processing resources.

B. IMPACT OF THE FILE POPULARITY
In Fig. 6 we assess the impact of the Zipf popularity parameter γ on the CHP performance under different mean file sizes µ. Note that for γ = 0.2 the popularity of contents is close to uniform (1% of files account for 2.8% popularity), whereas for γ = 2 a very small amount of video files concentrates a very high popularity (1% content account for 98.8% of popularity). Similar to Fig. 5 we observe that the popularity parameter γ has a small impact on the performance of the random content placement strategy. In more detail, we observe a small CHP deterioration of the random strategy for a small mean file size µ = 3GBs due to the fact that when a very small number of video files in M concentrates a high popularity (i.e. high γ values) the random strategy select with a higher probability a combination of files with lower popularity (i.e. more allocation options result in low CHP performance). On the contrary, the performance of both the proposed and the greedy strategies is shown to fast increase with the popularity parameter γ and even reach to C = 1 for γ > 1.4 under the fixed system parameters under scope. This performance trend readily follows from the fact that a higher γ parameter translates to the concentration of the popularity in M to lower volume of video files, enabling popularity-aware strategies to fill the cache sizes available in the MEC cluster with highly popular files while leaving less popular files out of the content placement process if necessary. Another interesting observation is that for the proposed and greedy strategies, the impact of the popularity parameter γ on the CHP performance strongly depends on the mean cache size µ for low popularity values γ (e.g. γ < 0.8).
The proposed strategy is shown to outperform the greedy strategy in terms of CHP probability, especially when the file size of popular videos is high. For example, for µ = 9GBs, the proposed strategy is shown to attain a double-fold increase on the CHP when the Zipf parameter is very low (e.g. γ = 0.2). Once again, the proposed strategy is shown to better handle the cache available in the MEC cluster even for larger video files, if we consider that the CHP of the proposed strategy for µ = 9GBs is higher compared to the CHP performance of the greedy strategy for µ = 6GBs, for all popularity parameter values under scope.
As expected, a lower mean file size µ enables all strategies to better handle the storage capacity available in the MEC cluster and increase the CHP performance. This readily follows by comparing the performance of any strategy for µ = 3GBs to the respective performance of the same strategy for µ = 6GBs. Nonetheless, a constant increase of the mean file size µ is shown to have different effects on the CHP performance of all strategies, independent of the γ value. For example, the CHP performance of the random strategy for µ = 3GBs is shown to increase almost three-fold as compared to the one for µ = 9GBs, whereas the CHP of the same strategy for µ = 3GBs does not increase two-fold as compared to the one for µ = 6GBs. Another interesting observation is that for low popularity values of γ , where the popularity distribution tends to be more uniform, the proposed strategy attains the highest CHP gains as compared to the greedy strategy. On the other hand, for high popularity parameters γ , the CHP performance of the greedy and the proposed strategies is comparable. This performance trend can be useful to scenarios where the MEC cluster head identifies that the popularity of files concentrates to small number of video files, enabling it to save processing resources by employing the greedy strategy instead of the proposed (exact) one.
In Fig. 7 we investigate the impact of the popularity skewness γ under a different number of SBS and FBS MHs. Note that as the number of SBS and FBS MHs increases, the available cluster cache size is considered to increase proportionally, i.e. the total pool of available cache resources in the cluster increases proportionally. Similar to Fig. 6, the CHP performance of the random strategy is shown to deteriorate with γ , independent of the number of MHs in the MEC cluster. Another interesting observation is that for all strategies, a two-fold increase on the number of high-end MHs (i.e. MHs with large cache capacity like SBSs in our simulations) is shown to provide significantly larger CHP gains as compared to the ones attained due to a similar two-fold increase on the number of low-end MHs (i.e. MHs with low cache capacity like FBSs in our simulations). This readily follows from the fact that SBSs are considered to host a 20x higher cache capacity as compared to FBSs, enabling the content placement strategies to better handle popular files of larger file sizes.
The CHP performance gap between the proposed and the greedy strategies is also shown to fast decrease as the popularity skewness parameter γ increases. Fig. 7 that increasing the number of high-end MHs can play a key role when the popularity of video files in M is spread across more files, i.e. the impact of N 1 dominates that of γ for low γ values, but the addition of more MHs will have a lower impact on the CHP performance when the popularity of files in M is concentrated in a lower number of files (i.e. for higher γ values). This performance trend can be used to adjust the MEC cluster size dynamically in view of the popularity distribution characterizing the library of popular video files, enabling the formation of additional MEC clusters with a lower number of MHs in order to better adapt the number (and structure) of MEC clusters to the spatial diversity of content popularity observed in a HCN. Accordingly, we derive a valuable cluster formation design guideline. If for a given geographical area a lower amount of files concentrates a higher popularity (i.e. higher γ values) but the content popularity distribution changes fast across neighbor geographical areas, the MNO can form a larger number of MEC clusters constituting by a lower volume of MHs to better adapt to the diverse popularity met across neighbor areas. On the other hand, if the content popularity is known to be similar across neighbor geographical areas, the MNO may choose to form a smaller number of MEC clusters with an increased volume of MHs to attain an enhanced network-wide CHP.
Another interesting observation is that the proposed content placement strategy can better adapt to the existence of a limited number of MHs in the MEC cluster while attaining a similar performance with that of the greedy strategy. In particular, we observe that the proposed strategy for N 1 = 10 attains a comparable performance with that of the greedy strategy for N 2 = 20 (double-fold increase of high-end MHs) even when the popularity parameter γ is mediumto-high (>0.6).

C. IMPACT OF THE MEAN CONTENT SIZE
In Fig. 8 we plot the cluster-wide CHP for increasing mean content size µ in M under different popularity parameters γ . As expected, when a larger content size µ is considered for popular video files in M, the CHP performance of all strategies deteriorates. This mainly follows from the fact that the available cache size on a per MH (and a cluster-wide) basis remains fixed while the size of the cached content increases. We observe a roughly linear performance deterioration for all strategies above the mean content size µ = 4GBs value. The performance deterioration is shown to strongly depend on the popularity distribution parameter γ .
For the different γ parameters plotted in Fig. 8, we observe that the performance of the random strategy remains roughly unaffected by γ , while a constant increase of the γ parameter (e.g. from 0.4 to 0.8, or 0.8 to 1.2) is shown to increase the CHP performance of both the proposed and the greedy strategies with a constant rate (e.g. for µ = 4 the CHP of the proposed increases by roughly 20% when γ increases by 0.4). Another interesting observation is that the performance gap between the proposed and greedy strategies increases with the mean content size of popular video files µ, highlighting that the proposed strategy can better cope with larger contents in M as compared to the greedy strategy. Fig. 9 investigates the CHP performance for increasing mean content size µ under a different number of SBS and FBS MHs on the CHP. Recall that an increase to the number of SBS, or FBS, MHs results in a proportional increase of the total cache size available in the cluster. For the given selection of the Zipf law parameter γ = 1.0, we observe that the impact of the number N 2 of FBS MHs is negligible on the CHP performance of both the proposed and the greedy strategy when a large number of high-end SBS MHs is considered (i. e. N 1 = 20). However, when the number of high-end MHs is lower (N 1 = 10), the respective CHP improvement observed by increasing two-fold the number of low-end MHs is larger for both the proposed and the greedy strategies. On the other hand, for the random strategy, we observe that the CHP performance shows notable improvement with a two-fold increase of either the SBS, or the FBS helpers, an improvement that is shown to be similar between the two scenarios (i.e. two-fold increase of N 1 results in similar improvements with a two-fold increase of N 2 ).
Interestingly, for all content placement strategies, the impact of increasing N 1 and N 2 is roughly the same on the CHP independent on the values taken by the µ parameter (e.g. the same improvement is observed while changing N 1 = 10 to N 1 = 20 independent of the values taken by µ and N 2 ). This performance trend indicates that increasing the number of MHs in the MEC cluster will result in the same CHP improvement, independent of the mean content size µ characterizing the files in library M.

D. IMPACT OF THE NUMBER AND TYPE OF CACHE-ENABLED MHs
In Fig. 10 we assess the impact of an increasing number of high-end SBS MHs under different values on the number of FBS MHs. As expected, the performance of the random strategy is shown to scale linearly with the number of SBS MHs N 1 in the MEC cluster. On the contrary, a fast improvement of the CHP performance is observed for both the proposed and the greedy strategies in lower N 1 values as the number of SBS MHs increases, especially when the number of FBS MHs is lower (e.g. compare N 2 = 10 and N 2 = 100 for an increase of N 1 from 1 to 4). This performance trend highlights that the addition of only a few high-end MHs (like the SBS in our simulations) has a high added value on the CHP performance, especially when the size of the MEC cluster is low.
On the other hand, a similar performance trend is observed for increasing the number of FBS MHs N 2 , when a high number of SBS MHs already exists in the MEC cluster. In more detail, as the N 1 value increases, the proposed and greedy strategies are shown to improve the CHP at a lower rate for the same increase of N 2 (e.g. for N 1 = 2 SBS MHs we observe a higher CHP improvement when N 2 changes from 10 to 40 as compared to that obtained for N 1 = 16 for the same N 2 increase). This performance trend can be valuable to the design of the cluster formation algorithm run by the MNO, as it highlights that the CHP improvement following from the addition of more MHs to a tagged MEC cluster should be examined in view of the current mixture of MHs in the cluster in order to maximize the added value following from the formation of a larger cluster. The underlying performance trade-off is that, on the one hand, the addition of more MHs can improve the CHP of a given MEC cluster but at the same time, the same number of MHs can be used to set up a new MEC cluster having a different library M that matches better the user requests on popular videos (which can be different in size and popularity for neighbor geographical areas). To this end, the MEC clustering algorithm should evaluate the addition of a new MH in the MEC cluster not only in light of the content library assumed per geographical area (and how good this adapts to the actual MEC service coverage) but also in view of the selected mixture of MHs allocated per MEC cluster.

E. IMPACT OF THE NUMBER OF POPULAR VIDEO CONTENTS IN M
In Fig. 11, we assess the impact of an increasing number of popular video contents in the library M under different popularity values γ . The CHP performance of the random strategy is shown to drop rapidly as the number of popular video contents increases, in a roughly independent fashion from the values taken by the Zipf parameter γ . Another interesting observation is that when the popularity of files in N is concentrated to a lower amount of video files in M, the performance of the greedy strategy is very close to that of the proposed (optimal) one. This performance trend can be exploited to save computations at the MEC cluster head upon Nonetheless, the CHP performance gap between the proposed and the greedy strategies is shown to rapidly increase with the library size |M| when the popularity is spread across more video files in M (i.e. γ < 0.8). This performance trend highlights the importance of employing more sophisticated planning of the cluster-based content placement when the popularity of video files in M is characterized by higher γ values. As compared to the greedy and random strategies, the proposed content placement strategy is shown to be highly-robust against an increase of the number of files in M as well as to a lower Zipf parameter γ .

F. PROCESSING OVERHEADS AND COMPUTATION TIME
In this section, we evaluate the performance of the three content placement strategies in terms of computation time necessary to complete the content allocation to the caches of MHs constituting the MEC cluster. Recall that this operation shall be deployed on an epoch-by-epoch basis and the allocated contents shall be replaced by new ones by the beginning of the next cache epoch. Thus, each epoch is expected to last for at least a few hours (or days). For our evaluations we have used a standard desktop PC equipped with i) Intel(R) Core(TM) i7-8550U CPU @1.8GHz, ii) DDR3 RAM of 8GBs, and iii) a 64-bit Windows 10 operating system. All strategies were implemented using a 64-bit version of Matlab R2018b and the respective computation time measurements were averaged over multiple samples (>100 per tick). Most of the computation time results have derived in line with the system parameter values used to derive the CHP measurement results of the previous subsections.
The main reason that led us measure that computation time necessary for completing the content placement allocation by each strategy is the fact that, in a general system parameter setup, the proposed strategy is exact and solves a NP-hard problem by exploiting the bound-and-bound search algorithm, which eliminates non-optimal solution branches a-priori (i.e. without exploring the entire state space of branches leading to sub-optimal allocations). As a general outcome of the simulation campaigns, we have observed that for the given set of system parameter values, which are in full accordance with practical content placement scenarios in medium-sized MEC clusters of HCN nodes, the proposed strategy requires only a few seconds to complete in a standard desktop PC. This result suggests that the proposed boundand-bound exact content placement strategy is both optimal and feasible in terms of processing overhead under realistic MEC deployment scenarios (i.e. when the number of MEC nodes is in the order of hundreds of cache-enabled HCN nodes).
Interestingly, the proposed exact content placement strategy typically required more computation time in parameter setups where the performance of the proposed strategy is very close to that of the greedy strategy, highlighting that such marginal scenarios can be identified a-priori by the MEC cluster head, which can switch from the proposed to the greedy content placement strategy. Nonetheless, we note that in all scenarios under scope, the computation time necessary for deploying the proposed optimal content placement strategy is in the order of a few seconds, enabling its practical deployment in MEC clusters consisting of a few hundreds of MEC-enabled nodes and a library size of thousands of popular video files.

1) IMPACT OF LIBRARY SIZE AND NUMBER OF MEC MHs
In Fig. 12 we plot the computation time necessary for completing the content placement allocation for an increasing number of video files in library M and different γ values. Note that the parameter values considered in this scenario are fully aligned with the ones used to derive the CHP performance of all strategies in Fig. 11. First of all we observe that the computation time necessary to complete for all content placement strategies is in the range of sub-seconds under all system parameter values under scope. We further observe that the computation time increases proportionally to the content library size |M| for all content placement strategies under scope. According to Fig. 12, the proposed content placement strategy is computationally feasible (sub-second computation time) in MEC scenarios where the number of MEC-enabled MHs is in the order of hundreds nodes, their cache size is in the order of a few GBs, the mean size of popular videos is in the order of a few GBs and the total number of popular video contents selected for the library M is in the order of a few thousands of files. As expected, the computation time necessary for the random strategy increases linearly with the size of the content library M, whereas the computation time for the greedy strategy is shown to scale with M in a roughly sub-squared fashion, due to the sorting algorithm employed to order video files based on their popularity on a per MH basis.
In Fig. 13 we plot the computation time required for the completion of all strategies assuming an increasing number of SBS and FBS MH values. Once again, the time necessary to complete the content placement logic for all strategies is in the range of sub-seconds. The performance of the greedy and the random strategies is shown to remain roughly unaffected by the number of MHs in the MEC cluster, including both SBS (N 1 ) and FBS (N 2 ) MHs. On the one hand, this is expected for the greedy strategy where the main processing overhead comes from the sorting popular video files f m ∈ M based on their popularity ρ m and scanning the order list until the cache size of each MH is filled. On the other hand, this is also expected for the random strategy where the files are randomly allocated in a MH-by-MH basis and the entire list of non-cached video files is to be scanned in order to concluded that no other file can fit into the cache of a given MH.
The computation time necessary to complete the proposed strategy is shown to increase linearly with the number of high-end SBS MHs, under all N 2 parameters under scope. The inclusion of additional low-end FBS MHs is also shown to add a roughly fixed computation overhead to the processing requirements of the proposed strategy, independent of the current value of the number of high-end SBS MHs. For example, this can be observed by comparing the computation time of the proposed strategy for N 2 = 100 and N 2 = 10 under different N 1 values. Notably, the computation time needed to complete the proposed strategy is shown to remain in the area of sub-seconds when the number of high-end SBS MHs reaches N 1 = 20 and the number of low-end FBS MHs is set to N 2 = 100, indicating that the proposed bound-and-bound content placement strategy can be readily deployed in medium-to-large sized MEC clusters (i.e. >120 MHs).

2) IMPACT OF SBS MHs' CACHE SIZE, ZIPF POPULARITY PARAMETER AND MEAN FILE SIZE
In Fig. 14 we plot the impact of the SBS/FBS cache size ratio β on the computation time of all content placement strategies, under different SBS cache size ξ 2 values. As in Fig. 4, we use parameter ξ 1 = β · ξ 2 to increase the SBS MH mean cache size ξ 1 in proportion to the FBS MH mean cache size ξ 2 . The value of ξ 2 is assumed to remain fixed. For β = 0 the MEC cluster consists of only FBS MHs, i.e. ξ 1 = 0 · ξ 2 . We start our discussion with the performance of the greedy and random content placement strategies. As shown in Fig. 14, the computation time necessary for completing the content placement under both the greedy and the random strategies is in the sub-second range. As expected, the random strategy requires less computation time compared to the greedy one, which is required to additionally order the (remaining) files based on their popularity.
When the available cache size in FBS MHs is ξ 2 = 20GBs, the computation time required for both the greedy and the random strategies is shown to drop with an increase of β. The aforementioned trend follows from the fact that both strategies run the content placement on a per MH basis as follows: i) pick a MH to fill its cache, ii) scan the list of popular video contents that have not been cached by previous MHs, and iii) sequentially select (based on popularity order, or randomly) a list of files to cache until the available cache of the MH is full. Files which cannot fit into the cache of a MH are skipped and the evaluation continues with the next ones in the list of non-cached files, until no other file can fit into the cache of the MH. Thus, in each iteration, the full list of remaining files will be scanned per MH. As the mean cache size of MHs increases, the number of non-cached files remaining for content placement decreases fast, reducing the overall computation time (Fig. 14). As a conclusion, the computation time required for the greedy and random strategies drops rapidly when the available cache of MHs in the MEC cluster is high.
Let us now discuss the performance of the proposed content placement strategy. As expected, the proposed strategy is shown to require more computation time compared to the random and greedy content placement strategies; however, its requirements are still in the scale of a few seconds. Hence, the proposed content placement strategy is not only exact but is also computationally feasible in scenarios where hundreds of MEC-enabled MHs perform coordinated content placement. In Fig. 14 we observe that under all ξ 2 values under scope, the computation time of the proposed strategy at its highest point for b = 0, drops to a minimum as b increases from 0 to low b values and then it increases again slowly with b. For example, when xi 2 = 20 GBs, the proposed strategy requires the highest computation time (11 seconds) for b = 0, reaches to the minimum requirement of 0.2 seconds for b = 1 and increases again slowly above b > 1. A similar performance trend is observed for other values of xi 2 (e.g. 4 and 8 GBs).
Recall that the proposed content placement strategy is based on a dynamic exploration of the full state space and uses upper/lower performance bounds to eliminate sub-optimal solution branches, reducing unnecessary computations whenever possible. Accordingly, the proposed strategy requires more computation time when the boundand-bound exploration methodology should go deeper into solution branches in order to assess their CHP performance. When the state space consists of solutions with diverse CHP performance values, e.g. due to the diverse cache sizes of MHs, bound-and-bound exploration enables fast elimination of sub-optimal solution branches avoiding in-depth examination. However, when the state space consists of solutions with similar CHP performance, e.g. due to similar file and cache size, bound-and-bound exploration should go deeper into the examination of solution branches before eliminating them, increasing the computation time.
When b is at the low end, cache diversity in the MEC cluster is weak and the cache sizes of MHs are roughly the same. Under this scenario, most of the solution branches involve the placement of files into similarly-sized MHs, enforcing the bound-and-bound exploration strategy to evaluate an increased volume of placement combinations with similar CHP performance. For that reason, in Fig. 14 we observe a different behavior of the proposed strategy when b is low (close to 1), as compared to the one for b taking mediumto-high values (e.g. b > 4). For example, when b = 0 we record the highest computation time for all ξ 2 values under scope (i.e. the MEC cluster includes only FBS MHs of similar size). However, as b increases, the cache diversity is more evident and the bound-and-bound strategy quickly reduces its computation time. Above a certain b value, which depends on the value of ξ 2 , cache diversity is well established and the performance of the proposed strategy scales with an increase of b, or ξ 2 . Once again, this performance trend follows from the fact that a larger value of b, or ξ 2 , enables the MEC cluster to cache more files, enforcing the bound-and-bound exploration strategy to investigate feasible solution branches in more depth and to increase its computation time.
Interestingly, when b is at the low end (i.e. SBS and FBS cache sizes are similar), a larger mean cache size ξ 2 reduces the computation requirements of the proposed strategy. This performance trend can be explained as follows. When a low cache diversity characterizes the MEC cluster (low b values) and the cache size available per MH is close to the mean file size µ = 4GBs, the state space is dominated by a vast volume of solutions with similar CHP performance that involve the placement of only a few files into the caches of similarly-sized MHs. As a result, bound-and-bound exploration requires more computation time to eliminate sub-optimal solutions. This effect is alleviated when the available cache size ξ 2 is larger, enabling an enhanced file placement diversity per MH to be achieved.
In Fig. 15 we examine the impact of the popularity distribution parameter γ and the mean file size µ on the computation time of all strategies, as the mean SBS cache size ξ 1 increases. The performance of the greedy and random content placement strategies remains roughly unaffected by the γ and µ values under scope, with a slight decrease of the required computation time observed when the mean SBS cache size is on the high-end of Fig. 15 and the mean file size is low (i.e. µ = 4GBs). The main reason of the reduced computation time necessary for both the greedy and random strategies is that a lower mean file size µ results in a higher content placement rate in the caches of MHs in the early steps of the strategies. To this end, as the caches of MHs are filled sequentially by both strategies, a smaller volume of non-cached files will be available for subsequent MHs thus, reducing the scanning time necessary for filling the cache of MHs examined at the final steps of the greedy and random strategies. A similar behavior has been discussed for both strategies in Fig. 14.
Let us now assess the performance of the proposed content placement strategy. As expected, the proposed strategy requires more computation time as compared to the baseline strategies. Nonetheless, the computation time of the proposed strategy still remains within feasible limits, which are of the order of a few seconds for all γ and µ parameters under scope. Notably, above a certain mean SBS cache size value ξ 1 , which is close to ξ 2 , we observe that the computation time remains roughly unaffected by the Zipf popularity parameter γ and the mean file size µ, e.g., for ξ 1 > 60 GBs. Similar to what we have observed in Fig. 14, this result follows from the fact that above a certain ξ 1 value, the content placement state space includes solution branches exhibiting a diverse CHP performance. This enables the proposed strategy to eliminate sub-optimal branches without going deeper into their assessment. Accordingly, as shown in Fig. 15, the impact of µ and γ is shown to be negligible, enabling the proposed strategy to scale its computation time requirements only with the mean cache size ξ 2 available at high-end SBS MHs. This follows from the fact that when the SBS cache size is very large, high-end MHs can fit an adequate number of popular video files, i.e. the large cache size dominates the impact of the file size and popularity on the computation time requirements.
On the other hand, similar to our findings from Fig. 14, when the mean SBS cache size value ξ 1 is comparable with the FBS mean cache size value of ξ 2 (which is set to 10 GBs in this setup), an additional computation overhead is observed for the proposed strategy (Fig. 15). Under this scenario, we observe that a larger mean file size µ increases the computation time of the proposed strategy, a performance that can be validated by comparing the plots of the proposed strategy for µ = 4 and µ = 8 GBs. This can be explained as follows: a larger mean file size µ lowers the 'effective' mean cache size of all MHs, reducing the average number of popular video files that are cached into the buffer of a given MH type. Besides, on the average, an SBS MH will cache ξ 1 /µ popular video files and a FBS MH will cache ξ 2 /µ files. This effect diminishes when the mean SBS cache size ξ 1 is high and the solution branches are highly diverse, enabling the proposed strategy to lower its computation time requirements (for ξ 1 > 60 GBs in Fig. 15).
When ξ 1 is at the low end, we further observe that the impact of the Zipf popularity parameter γ varies depending on the mean file size µ. As shown in Fig. 15, when µ is low, the Zipf parameter value has a negligible impact on the computation time performance, e.g. compare the plots of the proposed strategy for µ = 4 GBs γ = 1.2 and µ = 4 GBs γ = 0.8. However, when the mean file size µ is larger (mu = 8 GBs) and ξ 1 is at the low end, a larger Zipf parameter γ (less files concentrate the highest popularity) is shown to increase the computation time requirements of the proposed strategy. This performance trend follows from the fact that a higher mean file size µ reduces the average number of files cached per MH (as explained above) and that for γ = 1.2 less files concentrate the highest popularity, enforcing the proposed strategy to explore solution branches with similar CHP performance in more depth, i.e. branches that involve the placement of video files with low popularity.
Taking into consideration the results in Figs. 2 and 5, we conclude that a higher computation time is necessary for the proposed bound-and-bound exact content placement strategy mainly under marginal system parameter setups where the CHP performance of the proposed strategy is very close to that of the greedy strategy. The processing complexity of such marginal scenarios can be mitigated by the content placement decision making entity by switching to the greedy strategy, or employing relaxed upper performance bounds under the proposed strategy. It should also be noted that a very low computation time is required in scenarios where the proposed strategy exhibits superior performance as compared to the greedy and random strategies.

VI. CONCLUSION
In this paper, we have proposed a novel content placement architecture where cache-enabled mobile helpers (MHs) can be grouped into MEC-enabled clusters to perform cooperative content placement in view of a library of popular video files that remains fixed in size and popularity distribution. Using a ZOMKP formulation with respect to constraints on caching entire video files and not allowing an overlap of cached files within the same MEC cluster, we have presented an exact (optimal) content placement strategy that employs bound-and-bound enumerate search of the content placement state space, discarding solution branches that are identified to lead in sub-optimal performance.
Using extensive system-level simulations we have shown that the employment of the proposed bound-and-bound exact strategy is both efficient and computationally feasible in the context of cluster-based content placement in MEC-enabled heterogeneous cellular networks. Valuable design guidelines and best practices have been derived through the system-level simulation analysis, highlighting key performance trade-offs for MEC cluster formation and optimal content placement in MEC-enabled HCNs. Future work includes the design of MEC-enabled content delivery and cluster formation strategies in view of the results derived in this paper.
DIONYSIS XENAKIS received the Ph.D. degree from the Department of Informatics and Telecommunications, National and Kapodistrian University of Athens, Greece, in 2014. He has participated in numerous EU-funded projects and coauthored more than 30 peer-reviewed journal and conference papers. His current research interests include the design and analysis of 5G and beyond mobile data network technologies with the emphasis given in multi-access edge computing and distributed ledger technologies. He has served as a TPC member and the chair for top-tier IEEE conferences. He was a recipient of the Special Grant and Support Program by the Onassis Foundation. He has been a reviewer to high-ranking IEEE journals in computer science and data networks. He has authored more than 280 articles in the above areas. He is currently the Chairman of the board of the Greek Universities Network (GUNet).