Big Data Caching for Networking: Moving from Cloud to Edge

Not surprisingly, the exploitation of big data in mobile computing has been investigated recently in many works (see [10] for example). Caching at the edge of mobile wireless networks (namely BSs and user equipments) is also of high interest as evidenced in [6, 11, 12]. Briefly, technical misconceptions of caching for $5$G networks are introduced in [6]. A study on improving the video transmission in cellular networks via asynchronous content reuse of cache-enabled devices is given in [11]. Cooperative caching for delivering layered videos to mobile users is studied in [12].

Compared to existing works, our main contribution is to highlight and assess the potential gains of big data processing techniques for cache-enabled wireless networks, by using real traces of mobile users collected from BSs in a large urban area. To the best of our knowledge, none of the previous approaches has focused on deployment of a Hadoop-based big data processing platform inside a Mobile Operator (MO)’s core network in order to validate the performance gains of caching with real-data trials. By using tools from machine learning to predict content popularity, further improvements in user’s quality-of-experience (QoE) and backhaul offloading are achieved via proactive caching at the edge.

The rest of the paper is structured as follows. The role of big data and proactive edge caching in wireless networks is briefly discussed in Section II. An architecture based on big data platform and cache-enabled BSs is proposed in Section III. A practical case study is carried out in Section IV, where the traces collected from mobile operator’s network are processed on the big data platform and gains of proactive caching are validated via numerical simulations. We conclude in Section V and provide future directions.

Recently, data traffic patterns inside mobile operators’ data centers have changed dramatically. Big data has enabled high traffic exchange between gateway elements at backhaul. Although wireless technology has improved tremendously from 2G to 4G, backhaul connections of cellular networks have not seen such a rapid evolution. Hence, the mobile backhaul intra-traffic is slowly becoming larger than the inter-traffic between mobile backhaul elements and end-users. Indeed, in today’s carrier networks, in addition to handling mobile users’ traffic via mobile backhaul, fetching data from a number of different backend, database and cache servers, as well as the data generated by gateway and backhaul elements also contribute to this traffic load within the operator’s infrastructure. In fact, interactions of user terminal (UT) triggers various interactions with hundreds of servers, routers and switches inside the backhaul and core network. For example, for an original user’s HTTP request of $1$ KByte, the intranet data traffic can increase up to $930$x [13]. This is contrary to the traditional carrier network architecture which assumes client and wireless access nodes as bottlenecks lacking computational overhead rather than the backhaul infrastructure. Moreover, since data growth is a major challenge in today’s mobile infrastructures, managing this big data-driven networks in cloud environments is a pressing issue. For this reason, mobile edge computing (sometimes nicknamed "Fog" computing) is yet another emerging technology where edge devices provide cloud-computing like capabilities within the radio access network to carry out functionalities such as communication, storage and control [9]. However for 5G networks, it should be noted that deploying distributed cloud computing capabilities near to each BSs site (especially at locations where traffic volume is relatively low) may also increase the deployment cost considerably compared to centralised computing solutions due to availability of hundreds of sites in a typical MO. Moreover, for modelling and prediction of spatio-temporal users’ behaviour in user-centric 5G networks, network traffic arriving to a centralized location needs to be scaled out horizontally across servers and racks which is only feasible inside the core-site of a MO for proper analysis rather than distributed locations with relatively low traffic.

Owing to the recent developments in networking technology and standards as well as new forms of personal communications, big data has gained increased popularity especially inside data centers and mobile operators. With the enormous challenges of big data inside networking world, it is evident that the only way to cope with the growing network data traffic is through better data management and movement of data from cloud into the edge. In recent years, Hadoop has been successful as a big data management software solution offering dramatic cost savings over traditional tier-one database infrastructures, processing capabilities of various data formats and parallel processing over multiple nodes. Additionally, advanced analytic techniques in machine learning in conjunction with non-relational databases that can exploit big data (e.g. NoSQL databases) have increased the opportunity of understanding big data.

It is clear that moving contents’ proximity to the edge is important whenever user’s connectivity times out while performing streaming and/or downloading activities. To mitigate this, allowing data to be closer to users by reducing the distance of content to users and pushing the right content and applications at the edge yield better user experience. For instance, allowing Hadoop’s distributed data processing engine for analyzing users’ behaviour from enormous amount of streaming data (through the core site of MOs) as well as exploiting proactively caching strategic contents at edges (e.g. at BSs) can ease the backhaul traffic and improve users’ QoE by latency reduction. The following section discusses Hadoop-based big data processing platform and its relation with edge caching, as one way of dealing with big data inside MOs.

Let us assume a small cell network composed of $N$ small cells, where backhaul link and wireless link capacities of small cell $n$ are denoted by $C_{n}$ and $C^{\prime}_{n}$ respectively. We assume that $C_{n}<C^{\prime}_{n}$ reflecting a limited backhaul capacity scenario [5]. A set of users are requesting a total number of $D$ contents during $T$ time duration from a library of $\mathcal{F}=\{1,\ldots,F\}$ where each content $f$ in this library has a size of $L(f)$ with $L_{\mathrm{min}}<L(f)<L_{\mathrm{max}}$ and finite bit-rate requirement of $B(f)$ during its delivery. To offload the capacity-limited backhaul, small base stations (SBSs) are equipped with finite storage capacity and cache a subset of contents from the library $\mathcal{F}$. However, due to the sheer volume of contents and users, it is very challenging to process and extract useful information to cache users’ all contents at BSs, mainly due to limited storage constraints and lack of sufficient backhauls.

As alluded to earlier, minimizing the backhaul load via edge caching is very challenging. In this regard, a joint optimization of content popularity matrix (denoted by ${\bf P}$ where columns are contents, and rows are users or BSs depending on the scenario) and content cache placement at specific small cells are required while considering content sizes, bit rate requirements, backhaul, etc. Moreover, limited storage capacities of SBSs, the backhaul and wireless links, large library size and number of users with unknown ratings (i.e. empirical value of content popularity) have to be considered while dealing with a non-tractable cache decision [11]. Assuming that this non-tractable cache placement can be handled with greedy or approximate approaches (see [11, 12]), the SBSs learn and estimate the sparse content popularity/ratings. The following subsection is dedicated to this task.

In this section, a general big data processing framework for analyzing users’ data traffic is discussed. The purpose of this platform is to store users’ data traffic and extract useful information for proactive caching decisions. Supposing that Hadoop is deployed inside the core site of a MO, some of the requirements of this platform for our analysis are as follows:

• i)

  Huge Data Volume Processing in Less Time: In order to make proactive caching decisions, data processing platform inside the mobile core network infrastructure should be capable of reading and combining data from disparate data sources and delivering intelligent insights quickly and reliably. For this reason, after mirroring the data streaming interface through network analyzing tools, the collected raw data need to be exported into a big data storage platform such as Hadoop Distributed File System (HDFS) via enterprise data integration methods (such as Spring Integration) for detailed analysis.

• ii)

  Cleansing, Parsing and Formatting Data: Data cleansing is an essential part of the data analysis process. In fact, before performing any machine learning and statistical analysis on data, data itself has to be cleaned and usually this process takes more time than the machine learning analysis. Indeed, there are multiple steps involved in data cleansing process. First, raw data needs to be cleaned. The raw data itself might contain some malfunctioning, inappropriate and inconsistent packets with incorrect character encodings, etc. which need to be eliminated. The next step is to extract the relevant fields from the raw data itself. In this stage, the required headers from control and data packets that will be analyzed in later stages are extracted based on the data analysis and modeling requirements. Finally, the parsed data needs to be encoded accordingly (e.g. in Avro or Parquet format) for appropriate storage inside HDFS.

• iii)

  Data Analysis: Using the formatted data in HDFS, different data analytics techniques can be applied over header or/and payload information of both control and data planes using high level query languages such as Hive Query language (HiveQL) and Pig Latin. The aim of such a step is to find relationships between control and data packets, e.g. the location or Mobile Subscriber Integrated Services for Digital Network Number (MSISDN) of users (that are present in control packets but not in data packets) to the requested content (that are present only in data packets) through successive Map-Reduce operations.

• iv)

  Statistical analysis and visualizations: After machine learning analysis is done to predict the spatio-temporal user behaviour for proactive caching decisions, the results of the analysis can be stored and reused. Moreover, the results can be re-formatted to be used for further analysis using appropriate Extract, Transform and Load (ETL) tools, and can be input to other processing systems such as Apache Spark’s MLlib, etc. In addition, visualizations such as graphs and tables can be used to represent the data in a visual format for ease of understanding.

In such a platform, machine learning techniques which lie at the heart of recommendation-based engines can be applied so that users’ strategic contents can be inferred from a large amount of available data. In what follows, as a practical case study, we first analyse huge amount of users’ traffic on such a big data platform and use this data to estimate the content popularity matrix ${\bf P}$, which is essentially required for caching decision. Subsequently, we conduct a numerical study for showcasing the gains of caching at BSs.

In the numerical setup, we assume that $D$ contents are requested from the processed data (namely from final-traces table) over a time interval of $6$ hours $47$ minutes. Information on FRAME-TIME, HTTP-URI and SIZE are also taken from the final-traces table. Then, the requests are pseudo-randomly assigned to $N$ BSs. The wireless link capacities of small cells, backhaul link and storage capacities are set to identical values within each other for ease of revealing the caching gains. The list of simulation parameters are summarized in Table I. The global procedure contains the following two major steps:

• •

  Estimation of content popularity ${\bf P}$ (where columns are contents, and rows are BSs): This is done on the big data platform by processing large amount of collected data and exploiting machine learning tools. Two methods are examined in the numerical setup:

  • i)

    Ground Truth: The ${\bf P}$ matrix is constructed by considering all available information in the final-traces table. The matrix has $6.42\%$ of rating density in total.

  • ii)

    Collaborative Filtering: $30\%$ ratings available in the final-traces table are picked uniformly at random for training of ${\bf P}$ matrix estimation. Then, the remaining missing entries/ratings in the traces are predicted via the regularized singular value decomposition (SVD) from collaborative filtering (CF) methods [15].³³3Regularized SVD is chosen due to its outperforming performance with respect to other CF methods [15].

• •

  Caching strategic contents: The cache decision procedure at the base stations is made by storing the most-popular contents greedily at the SBSs until no storage space remains as in [1].⁴⁴4This greedy approach is chosen for ease of exposition. Once can also employ online cache placements strategies (e.g. least recently used (LRU), least frequently used (LFU))..

As regards to the performance metrics: i) request satisfaction, as QoE metric, is defined as the amount of contents delivered at a given target rate, and ii) backhaul load corresponds to the percentage of the traffic passing over the backhaul links over the total possible traffic volume induced by the content requests. A detailed analytical formulas of request satisfaction and backhaul load can be found in  [1].

In this section, based on the available information in the final-traces table, we conduct a numerical study to reveal the gains of caching. The impact of storage size on the users’ request satisfaction is plotted in Fig. 2. Therein, $0\%$ of storage size corresponds to no caching, whereas $100\%$ of storage is equivalent to caching the entire library ($17.7$ GByte). In the figure, we note that the users’ request satisfaction has a monotonically increasing behaviour, and somewhat intuitive, $100\%$ of satisfaction is achieved in both methods when the complete content catalog (with $100\%$ of storage size) is stored by fixing parameters in our setting to plausible (and realistic) values in order to see the regimes where $100\%$ satisfaction is achieved. However, a performance gap between the ground truth and CF is observed until $79\%$ of storage size which is mainly due to the estimation errors. For instance, when the BSs have $40\%$ of storage size for caching, the ground truth yields $89\%$ of satisfaction whereas the performance of CF stays at $75\%$.

Fig. 2 also shows the impact of storage size on the backhaul load/usage. In the figure, we see that both methods yield less backhaul load (namely higher offloading gains). For instance, having $79\%$ of storage size at BSs, both methods offload $98\%$ of backhaul. However, the ground truth outperforms the CF method since it has complete information of the content ratings. On the other hand, after a certain storage size, a dramatical decrease of backhaul is observed in both approaches. Compared to previous works which mostly consider identical content sizes, we are dealing with real traces with non-identical content sizes.

In the simplest form, one can write the backhaul load of a particular content as $load=popularity\times size$, if not cached. Therefore, a relatively less popular but very big-sized contents might lead to such a behaviour on the backhaul load, if not cached at the SBSs. This points out the importance of taking into account contents sizes in caching decision which reflects a more practical/realistic characterization of backhaul usage.

Fig. 3 illustrates the evolution of users’ request satisfaction with respect to the backhaul capacity ratio, defined as the ratio of total backhaul link capacity $\sum_{n}{C_{n}}$ over total wireless link capacity $\sum_{n}{C^{\prime}_{n}}$. It is clear from the figure that increasing the backhaul link capacity yields higher satisfactions, both in ground truth and CF approaches. This is due to the fact that bottleneck in the backhaul becomes less relevant with the increment of this ratio.

The above performance results demonstrate the case with $30\%$ of rating density in CF. However, it is clear that increasing the training rating density of CF, less estimation error and hence closer satisfaction gains to ground truth is expected. In order to show this, Fig. 4 demonstrates the effect of training rating density on root-mean-square error (RMSE) where the error is defined as the root-mean-square of the difference between users’ content satisfaction of the ground truth and CF approaches over all possible storage sizes. Fig. 4 clearly validates the fact that performance of CF can be improved via higher training rating density.