An Efficient Coded Streaming Using Clients’ Cache

Abstract

As multimedia traffic has been increasing and is expected to grow more sharply, various technologies using caches have been attracting lots of attention. As one breakthrough technology to deal with the explosively growing traffic, exclusive OR (XOR)-based index coding has been widely investigated because it can greatly enhance the efficiency of network resource by reducing the number of transmissions. In this paper, we investigate how to apply XOR-based index coding to large-scaled practical streaming systems for video traffic that accounts for more than 70% of total Internet traffic. Contrary to most previous studies that have focused on theoretical analysis of optimal performance or development of optimal index coding schemes, our study proposes a new XOR coding-based video streaming (XC). We also propose a new grouping algorithm for creating XC groups while guaranteeing the complete backward compatibility of XC with existing streaming schemes such as unicast (UC), multicast (MC), and broadcast (BC). The performance of the proposed scheme is analyzed in two steps. First, the behavior of video contents in caches at clients is modeled as a Markov chain, and the steady-state probabilities and caching probabilities for each piece of video content are derived. Based on the probabilities, the performance of the proposed system is then analyzed in terms of the average number of connections that each client requires in order to receive one video content. Our numerical results show that the proposed video streaming scheme using XC can reduce the average number of transmissions by up to 18%, compared to the conventional scheme.

1. Introduction

A recent study showed that the total amount of Internet traffic will increase three-fold over five years from 2017 to 2022, and video traffic would be growing more sharply than other types of traffic [1]. More specifically, it was predicted that the video traffic that accounted for about 75% of total Internet traffic in 2017 would increase to about 82% in 2022. It was also revealed by another interesting study that the most popular 50 videos accounted for almost 80% of the total number of views in a major over-the-top (OTT) service provider, YouTube [2]. Video service providers deploy huge content delivery systems and manage their own systems to meet the increasing demand, but the approach causes a tremendous cost to the companies [3]. An alternative is to use caching [4,5]. If a requested content exists in the cache of a nearby proxy server, clients can receive the cached copy, which typically reduces delivery time. Recently, the concept of caching has been extended to wireless multimedia streaming systems to cope with the sharply increasing data traffic by offloading increasing video traffic or improving the spectral efficiency of wireless networks [6,7,8,9,10,11,12,13,14,15]. The problem of caching placement was investigated, and some state-of-the-art solutions were introduced in [6,7,8,9]. A dynamic deep reinforcement learning-based management framework for virtual cache slicing was proposed to manage the limited cache resources when service providers share a common physical infrastructure [6]. A probabilistic caching placement was investigated to control cache-based channel selection diversity and network interference in a stochastic wireless caching helper network [7]. A tradeoff between the content diversity gain and the cooperative gain according to content placements was investigated and a probabilistic content placement to optimally balance the tradeoff was proposed [8]. Device-to-device (D2D) caching network, where each node caches some contents and another node can receive these contents directly from its nearby nodes instead of a remote service provider, was investigated in [10,11].

Contrary to previous studies that considered transmitters with cache and studied how to use the transmitters’ cache efficiently, some studies focused on clients with cache [12,13,14,15,16,17,18,19]. If a client wants to play a content which has been stored in its cache, the content can be played directly from the cache with no outbound connection. A joint problem of content pushing and recommendation for cache-enabled mobile users was formulated and a reinforcement learning-based framework for maximizing the profit of mobile network operators was proposed in [12]. Novel transmission techniques based on state-of-the-art interference management schemes such as interference cancellation, zero-forcing, and interference alignment were proposed for cache-aided radio access networks where edge nodes and user equipment are both equipped with cache [13]. An erasure broadcast network was investigated considering two disjoint sets of receivers: a set of weak receivers with an equal size of cache and a set of strong receivers with no cache [14]. It was proposed to exploit limited cached packets as side information to cancel incoming interference at the receiver side in a stochastic network where the random locations of base stations and users are modeled by Poisson point process [15].

Moreover, more advanced transmission schemes that use the contents stored in clients’ cache more efficiently were proposed to improve the efficiency of limited network resource [16,17,18,19]. If a transmitter has the perfect information of contents stored in clients’ caches, the transmitter can transmit multiple contents requested by different clients at once by using XOR index coding and each client can recover its content by performing XOR operations of the XOR coded data and contents stored in its cache, which can enhance the efficiency of network resource by reducing the number of transmissions [16]. The exact broadcast rate which had remained unknown was analyzed using linear programs [17]. A simple inner bound was established on the general index coding problem and it was demonstrated that the inner bound is tight for all index coding problems of up to five messages [18]. A pruning algorithm that can find the optimal clique cover index code and transmission time allocation for minimizing wireless outage probability was proposed to reduce a computational complexity of a brute-force searching algorithm [19]. Most of aforementioned studies were devoted to theoretical research to analyze optimal performance or to develop optimal coding schemes, and they are not thus sufficient to be applied to real large-scaled video streaming systems. In addition, the real advantages of the index coding-based video streaming and its compatibility with existing streaming schemes have never been verified.

In this paper, we thus propose a new video streaming system that supports XC. We also propose a new grouping algorithm for creating XC groups while guaranteeing the complete backward compatibility of XC with existing streaming schemes such as UC, MC, and BC. The performance of the proposed system is analyzed and compared with that of a conventional streaming system to verify its gain. We first model the behavior of contents in caches at clients as a Markov chain and derive the steady-state probabilities and caching probabilities for each video to mathematically analyze the statistical characteristics of caches at clients in video streaming systems. Based on the statistical characteristics of caches, the performance of the proposed system is analyzed in terms of the average number of connections that each client requires in order to receive one video content. The proposed scheme can be widely applied for various types of networks including mobile networks and sensor networks with video streaming.

The rest of this paper is organized as follows. In Section 2, a video streaming system where clients are equipped with cache, and we derive the steady-state probabilities and caching probabilities for each video based on a Markov chain. A new video streaming system for supporting XC is proposed and a grouping algorithm for the proposed streaming system is also described in Section 3. Numerical results are shown in Section 4, and the conclusions of this paper are drawn in Section 5.

2. A Streaming System Using Clients’ Cache

We investigate a video streaming system with a single streaming server and N clients, which is illustrated in Figure 1. The streaming server and each client are all equipped with cache that can store up to V and C videos $(V>C)$, respectively. It is assumed that all videos have the same size. ${\mathbb{C}}_n$ denotes the cache of client n and $|{\mathbb{C}}_n|=C\forall n.$ If each client plays video contents independently of others, the statistical characteristics of cache at each client will be identical and hence, we omit the index n for a simplicity of the notation, now and hereafter. $\mathbb{C}\left(s\right)$ denotes the video that is stored in the s-th memory of a cache $\mathbb{C}$, where $1\le s\le C$. Thus, $\mathbb{C}\left(1\right)$ and $\mathbb{C}\left(C\right)$ indicate the most recently used video and the least recently used video, respectively. ${\mathbb{L}}_s$ denotes a set of videos used later than $\mathbb{C}\left(s\right)$ and is given by

$${\mathbb{L}}_s=\left\{\begin{array}{cc}\left\{\mathbb{C}\right(1),\dots ,\mathbb{C}(s-1\left)\right\},& \mathrm{if}s\ne 1\\ \varnothing ,& \mathrm{if}s=1.\end{array}\right.$$

(1)

${\mathbb{R}}_s$ denotes a set of videos used earlier than $\mathbb{C}\left(s\right)$ and is given by

$${\mathbb{R}}_s=\left\{\begin{array}{cc}\left\{\mathbb{C}\right(s+1),\dots ,\mathbb{C}(C\left)\right\},& \mathrm{if}s\ne C\\ \varnothing ,& \mathrm{if}s=C,\end{array}\right.$$

(2)

and can be also obtained by ${\mathbb{R}}_s=\mathbb{C}\backslash {\mathbb{L}}_s\backslash \left\{\mathbb{C}\left(s\right)\right\}=\mathbb{C}\backslash \{\mathbb{C}\left(1\right),\dots ,\mathbb{C}\left(s\right)\}$.

The normalized popularity of a video that ranks v-th can be predicted by Zipf distribution [20,21], which is given by

$$f_v=\frac{1/v^{\alpha }}{{\sum }_{n=1}^V\left(1/n^{\alpha }\right)},1\le v\le V,$$

(3)

where $f_v$ satisfies ${\sum }_{v=1}^V{f}_v=1$ and $\alpha$ is the exponent characterizing Zipf distribution [22]. Zipf distribution with $\alpha =0$ turns into a uniform distribution, by which all V videos have the same normalized popularity, $\frac{1}{V}$. We use the least recently used (LRU) algorithm as a cache replacement strategy [23], by which clients’ caches are autonomously updated without consuming extra network resource after streaming a video content. If a client wants to play a video content v that is not stored in the cache, which denotes $v\notin \mathbb{C}$, the content v will be streamed by one of MC, XC, or UC. After playing the content v, LRU discards $\mathbb{C}\left(C\right)$, which is the least recently used one, and the content v will be stored in the first place of the cache after shifting all contents in the cache to the right. Thus, $\mathbb{C}$ will be updated as $\mathbb{C}=\{v,\mathbb{C}(1),\dots ,\mathbb{C}(C-1\left)\right\}$. On the other hand, if a client wants to play a content v stored in the s-th place of the cache, which denotes $v=\mathbb{C}\left(s\right),1\le s\le C$, the content v will be directly played by local playing (LC) from the cache without using any network resource for streaming. Then, the content v will be re-located to the first place of the cache to ensure that the most recently used content will stay in the cache the longest. The contents in ${\mathbb{L}}_s$ will be only shifted to the right, while there will be no change on contents in ${\mathbb{R}}_s$. Thus, $\mathbb{C}$ will be updated as $\mathbb{C}=\{v,\mathbb{C}(1),\dots ,\mathbb{C}(s-1),\mathbb{C}(s+1),\dots ,\mathbb{C}(C\left)\right\}$. The case of $s=1$ denotes that the same content has been being played twice in a row and there is then no change on the cache.

A certain content $k(1\le k\le V)$ might be stored in the client’s cache or might not be stored. In the case that content k is stored in the cache, the content k can have C states based on its stored location. Thus, each content k can have total $(C+1)$ states in $\mathbb{C}$. The $(C+1)$-th state denotes that the content is not stored in the cache. The behavior of content k in the cache can be modeled by a Markov chain, as depicted in Figure 2. Transition probability $p_k^{sj}$ denotes a probability that a content k staying at state s moves to state j after a client plays the content v.

For the case of $s=1$, a content k staying in the first place has two possibilities of transition. If $v=k$, which means that a client plays the content k by using LC, the video k will be still staying in the first place with no transition. Otherwise, it will move to the second place. Two transition probabilities are thus given as

$$\begin{array}{ccc}\hfill p_k^{11}& =& Pr[v=k]=f_k\hfill \end{array}$$

(4)

$$\begin{array}{ccc}\hfill p_k^{12}& =& Pr[v\ne k]=1-p_k^{11}=1-f_k.\hfill \end{array}$$

(5)

For the case of $2\le s\le C$, a content k has three possibilities of transition. If $v=k$, then the content k will be played by LC and move to the first place after being played. If $v\in {\mathbb{L}}_s$, the content k will have no transition. Finally, if $v\in {\mathbb{R}}_s\mathrm{or}v\notin \mathbb{C}$, the content k will be shifted to the right and thus move to the $(s+1)$-th place. The corresponding transition probabilities are given as

$$\begin{array}{cc}\hfill p_k^{s1}& =Pr[v=k]=f_k\hfill \end{array}$$

(6)

$$\begin{array}{cc}\hfill p_k^{ss}& =Pr[v\in {\mathbb{L}}_s]\hfill \end{array}$$

(7)

$$\begin{array}{cc}\hfill & =\sum _{X\in {}_{{\tilde{\mathbb{V}}}_k}{\mathbb{P}}_{s-1}}\frac{\prod _{x\in X}{f}_x}{{\sum }_{X\in {}_{{\tilde{\mathbb{V}}}_k}{\mathbb{P}}_{s-1}}{\displaystyle \prod _{x\in X}}{f}_x}\sum _{x\in X}{f}_x\hfill \end{array}$$

(8)

$$\begin{array}{cc}\hfill p_k^{s(s+1)}& =Pr\left[v\in {\mathbb{R}}_s\mathrm{or}v\notin \mathbb{C}\right]=1-p_k^{s1}-p_k^{ss},\hfill \end{array}$$

(9)

where ${\tilde{\mathbb{V}}}_k$ denoting the index set of contents except for k can be obtained by

$${\tilde{\mathbb{V}}}_k=\mathbb{V}\backslash \left\{k\right\}=\{1,2,\dots ,k-1,k+1,\dots ,V\},$$

(10)

and ${}_{\mathbb{X}}{\mathbb{P}}_n$ denotes a set that consists of all possible permutations of choosing n objects from a set $\mathbb{X}$. Thus, ${}_{{\tilde{\mathbb{V}}}_k}{\mathbb{P}}_{s-1}$ denoting a set of all possible $\frac{(V-1)!}{(V-s)!}$ permutations of $(s-1)$ contents that can be chosen from the set ${\tilde{\mathbb{V}}}_k$ represents all possible combinations of ${\mathbb{L}}_s$. For the case of $s=C+1$, the content k has two cases of transition. If $v=k$, the content k move to the first place after being played. Otherwise, the content k will be discarded from the cache. The corresponding transition probabilities are given as

$$\begin{array}{ccc}\hfill p_k^{(C+1)1}& =& Pr[v=k]=f_k\hfill \end{array}$$

(11)

$$\begin{array}{ccc}\hfill p_k^{(C+1)(C+1)}& =& Pr[v\ne k]=1-p_k^{(C+1)1}=1-f_k.\hfill \end{array}$$

(12)

A square matrix consisting of state transition probabilities for the content k is defined as

$${\mathbf{P}}_k\triangleq \left[p_k^{ij}\right],1\le i\le C+1,1\le j\le C+1,$$

(13)

the size of which is $(C+1)\times (C+1)$. Let $s_i$ be a steady-state probability that the content k is staying in state i at an arbitrary moment. Then, ${\mathbf{s}}_k=[s_1,s_2,\dots ,s_{C+1}]$ denoting the vector consisting of steady-state probabilities for all states for the content k can be obtained by solving the following equation [24]:

$$\begin{array}{cc}& {\mathbf{s}}_k\times {\mathbf{P}}_k={\mathbf{s}}_k\\ & \mathrm{subject}\mathrm{to}{\sum }_{i=1}^{C+1}{s}_i=1.\end{array}$$

(14)

The solution of (14) can be obtained by several approaches and we, in this paper, use a pseudo inverse-based approach [24]. The equation in (14) can be rewritten as

$$\begin{array}{cc}& {\mathbf{s}}_k\times \left[{\mathbf{P}}_k-\mathbf{I}\right]=\mathbf{0}\\ & \mathrm{subject}\mathrm{to}{\sum }_{i=1}^{C+1}{s}_i=1,\end{array}$$

(15)

where $\mathbf{I}$ and $\mathbf{0}$ denote an identity matrix with the same size as ${\mathbf{P}}_k$ and a row vector with $(C+1)$ zeros, respectively. The constraint in (15) can be incorporated into the equation as

$${\mathbf{s}}_k\times \left[({\mathbf{P}}_k-\mathbf{I})|\mathbf{1}\right]=\left[\mathbf{0}|1\right],$$

(16)

by appending $\mathbf{1}$, which is a column vector with $(C+1)$ ones, to the right of the matrix $({\mathbf{P}}_i-\mathbf{I})$ and 1 to the right of the vector $\mathbf{0}$, respectively. Let $\left[({\mathbf{P}}_k-\mathbf{I})|\mathbf{1}\right]=\mathbf{Q}$ and $\left[\mathbf{0}|1\right]=\mathbf{b}$, then (16) can be rewritten as ${\mathbf{s}}_k\mathbf{Q}=\mathbf{b}$ and ${\mathbf{s}}_k$ can be obtained as

$${\mathbf{s}}_k=\mathbf{b}{\mathbf{Q}}^T{\left(\mathbf{Q}{\mathbf{Q}}^T\right)}^{-1}.$$

(17)

When a client wants to play the video content k at an arbitrary moment, the probability that the content is stored in the cache is calculated as

$$c_k=\sum _{i=1}^C{s}_i,$$

(18)

while the probability that the content k is not stored in the cache at the arbitrary moment is given as $s_{C+1}$ that can be calculated by $s_{C+1}=1-c_k$.

Figure 3 shows probabilities $c_k$’s for various k values, $C\in \{1,2,3\}$, $V=10$, and $\alpha \in \{0,1,1.5\}$. For $C=1$, $c_k$’s are the same as normalized popularity values given by Zipf distribution because the current content stored in a cache is the content that a client requested according to Zipf distribution. As C increases, all $c_k$’s increase regardless of the ranks of contents, k. As explained in (3), $\alpha =0$ makes all contents have the same popularity and $c_k$’s are thus all the same for all k’s. As $\alpha$ increases, $c_k$’s of upper rank contents increases while $c_k$’s of lower rank contents decrease.

3. Proposed Streaming Scheme Using XOR-Based Coding

The XOR operation has the zero-identity, by which $\mathbf{A}\oplus \mathbf{0}=\mathbf{0}\oplus \mathbf{A}=\mathbf{A}$ is satisfied for a given bit stream $\mathbf{A}$, where $\mathbf{0}$ is the bit stream consisting of 0 and it has the same length as $\mathbf{A}$. It also has the property of self-inverse satisfying $\mathbf{A}\oplus \mathbf{A}=\mathbf{0}$. In addition, XOR is not only commutative, but also associative. Figure 4 illustrates a simplified concept of XC which is a video streaming scheme using XOR coding based on the four aforementioned properties. Client 1 wants to stream $v_1$ with $v_2$ cached in ${\mathbb{C}}_1$, and client 2 wants to stream $v_2$ with $v_1$ cached in ${\mathbb{C}}_2$. Contrary to a conventional scheme where a streaming server transmits $v_1$ and $v_2$ by UC using two separate connections, XC generates the coded bit stream $v_1\oplus v_2$ and transmits it by using a single connection. Then, client 1 and 2 reconstruct $v_1$ and $v_2$ from $v_1\oplus v_2$ by using their cached data as

$$\begin{array}{cc}\hfill (v_1\oplus v_2)\oplus v_2& =v_1\oplus (v_2\oplus v_2)=v_1\oplus \mathbf{0}=v_1\hfill \\ \hfill (v_1\oplus v_2)\oplus v_1& =(v_2\oplus v_1)\oplus v_1=v_2\oplus (v_1\oplus v_1)=v_2\oplus \mathbf{0}=v_2,\hfill \end{array}$$

(19)

respectively. In this section, we propose a new transmission algorithm for supporting XC while guaranteeing a backward compatibility with conventional streaming schemes such as LC, UC, MC, and BC, that have been widely used to transmit video contents.

3.1. A Case Study with Two Clients ($N=2$)

To clearly explain the proposed transmission scheme, we first consider a special case with two clients, i.e., $N=2$, and the proposed transmission scheme will be then extended to the general case to support multiple clients, i.e., $N\ge 2$, in the following subsection. Suppose that clients 1 and 2 want to play $v_1=i$ and $v_2=j$, respectively. Each client first checks if the content to play is stored in its cache before requesting the content to a streaming server. If the content is stored in its cache, the client plays the content directly from the cache by LC without an outbound connection. Otherwise, the client transmits a request message including the information of the content to request and the contents of its own cache to a streaming server. Let ${\rho }_{i,j}^n$ be the probability that the number of connections required to transmit i and j is equal to n for given $v_1=i$ and $v_2=j$, where $n\in \{0,1,2\}$ and $1\le i,j\le V$. For the case of $v_1\in {\mathbb{C}}_1$ and $v_2\in {\mathbb{C}}_2$, no connection is required to transmit $v_1$ and $v_2$. Thus, ${\rho }_{i,j}^0$ can be defined as

$${\rho }_{i,j}^0=Pr\left[(i\in {\mathbb{C}}_1)\cap (j\in {\mathbb{C}}_2)\right],$$

(20)

and the average total probability that the number of required connections is 0 can be calculated as

$$Pr[n=0]=\sum _{i=1}^V\sum _{j=1}^V{f}_i{f}_j{\rho }_{i,j}^0=\sum _{i=1}^V\sum _{j=1}^V{f}_i{f}_j{c}_i{c}_j,$$

(21)

by averaging ${\rho }_{i,j}^0$ over all combinations of i and j.

For given i and j, the probability ${\rho }_{i,j}^1$ is defined as

$$\begin{array}{cc}\hfill {\rho }_{i,j}^1& =Pr\left[\right[(i\notin {\mathbb{C}}_1)\cap (j\in {\mathbb{C}}_2)]\cup \left[(i\in {\mathbb{C}}_1)\cap (j\notin {\mathbb{C}}_2)\right]\hfill \end{array}$$

(22a)

$$\begin{array}{cc}\hfill & \cup [(i\notin {\mathbb{C}}_1)\cap (j\notin {\mathbb{C}}_2)\cap (i=j)]\hfill \end{array}$$

(22b)

$$\begin{array}{cc}\hfill & \cup [(i\notin {\mathbb{C}}_1)\cap (j\notin {\mathbb{C}}_2)\cap (i\ne j)\cap (i\in {\mathbb{C}}_2)\cap (j\in {\mathbb{C}}_1)]],\hfill \end{array}$$

(22c)

where Equation (22a) denote the probability that only one client is supported by UC because only one of $v_1$ and $v_2$ is in their own cache. Equation (22b) is the probability that clients are supported by MC because they request the same content, i.e., $v_1=v_2$, which is not in the clients’ caches. Equation (22c) is the probability that clients are supported by XC because each client does not have the own request content, i.e., $v_1\notin {\mathbb{C}}_1$ and $v_2\notin {\mathbb{C}}_2$, but has the content requested by the other client in cache, $v_1\in {\mathbb{C}}_2$ and $v_2\in {\mathbb{C}}_1$. In this case, clients 1 and 2 can reconstruct $v_i$ and $v_2$ from $v_1\oplus v_2$, respectively. Then, the average total probability that the number of required connections is 1 can be calculated as

$$\begin{array}{cc}\hfill Pr[n=1]& =\sum _{i=1}^V\sum _{j=1}^V{f}_i{f}_j{\rho }_{i,j}^1\hfill \end{array}$$

$$\begin{array}{cc}\hfill & =\sum _{i=1}^V\sum _{j=1}^V{f}_i{f}_j\left[(1-c_i)c_j+c_i(1-c_j)\right]\hfill \end{array}$$

(23a)

$$\begin{array}{cc}\hfill & +\sum _{i=1}^V\sum _{j=1,j=i}^V{f}_i{f}_j\left[(1-c_i)(1-c_j)\right]\hfill \end{array}$$

(23b)

$$\begin{array}{cc}\hfill & +\sum _{i=1}^V\sum _{j=1,j\ne i}^V{f}_i{f}_j\left[(1-c_i)(1-c_j)c_j{c}_i\right]\hfill \\ \hfill & =\sum _{i=1}^V\sum _{j=1}^V{f}_i{f}_j\left[c_i+c_j-c_i{c}_j\right]\hfill \\ \hfill & +\sum _{i=1}^V{f}_i^2\left[{(1-c_i)}^2\right]\hfill \\ \hfill & +\sum _{i=1}^V\sum _{j=1,j\ne i}^V{f}_i{f}_j\left[(1-c_i)(1-c_j)c_j{c}_i\right],\hfill \end{array}$$

(23c)

by averaging ${\rho }_{i,j}^1$ over all combinations of i and j.

Finally, for given i and j, ${\rho }_{i,j}^2$ is defined as

$${\rho }_{i,j}^2=Pr\left[(i\notin {\mathbb{C}}_1)\cap (j\notin {\mathbb{C}}_2)\cap {\left[(i\in {\mathbb{C}}_2)\cap (j\in {\mathbb{C}}_1)\right]}^{\complement }\right],$$

(24)

where $A^{\complement }$ denotes the complement of a set A. Then, the average total probability that the number of required connections is 2 can be calculated as

$$\begin{array}{cc}\hfill Pr[n=2]& =\sum _{i=1}^V\sum _{j=1}^V{f}_i{f}_j{\rho }_{i,j}^2\hfill \\ \hfill & =\sum _{i=1}^V\sum _{j=1}^V{f}_i{f}_j\left[(1-c_i)(1-c_j)(1-c_j{c}_i)\right],\hfill \end{array}$$

(25)

by averaging ${\rho }_{i,j}^2$ over all combinations of i and j. In this case, clients are supported by UC through two independent connections, respectively.

3.2. A Transmission Algorithm Extended for Multiple Clients ($N\ge 2$)

In this subsection, we propose a transmission algorithm by extending the transmission for two clients described in the previous subsection in order to support XC for $N(N\ge 2)$ clients, while guaranteeing a backward compatibility with conventional streaming schemes such as LC, UC, and MC. Our algorithm consists of two phases. In the first phase, a client $n(1\le n\le N)$ is categorized into LC or MC based on the requesting content, $v_n$, and cache status, ${\mathbb{C}}_n$, or proceeds to the second phase. The clients satisfying $v_n\in {\mathbb{C}}_n$ will be served by LC and become the elements of ${\mathbb{U}}_L$, which is a set of clients served by LC. The remaining clients with $v_n\notin {\mathbb{C}}_n$, given by $\mathbb{T}=\{1,\dots ,N\}\backslash {\mathbb{U}}_L$, transmit a request message to a streaming server including a content to play and cache information. If two or more clients request the same video content, they are all categorized into an MC group. The MC group becomes an element of ${\mathbb{G}}_M$, which is a set consisting of MC groups, and the cardinality of ${\mathbb{G}}_M$ is $0\le |{\mathbb{G}}_M|\le \lfloor \frac{\left|\mathbb{T}\right|}{2}\rfloor$ because an MC group consists of at least two clients. ${\mathbb{U}}_M$ is composed of all clients included in ${\mathbb{G}}_M$.

In the second phase, the clients who are not included in either ${\mathbb{U}}_L$ or ${\mathbb{U}}_M$, given by $\mathbb{T}=\{1,\dots ,N\}\backslash {\mathbb{U}}_L\backslash {\mathbb{U}}_M$, are categorized into XC or UC groups. A client n in $\mathbb{T}$ is first checked to see if it can be served by XC. For an existing XC group S, the client n can join the existing XC group S only if the following conditions are satisfied:

$$\begin{array}{cc}\hfill {\mathbb{C}}_n& \ni v_m\forall m\in S,\hfill \\ \hfill v_n& \in {\mathbb{C}}_m\forall m\in S.\hfill \end{array}$$

(26)

If there is no existing XC group or the client n fails to join any existing XC group, the client n attempts to create a new XC group with another client m who is included in $\mathbb{T}$ and satisfies

$$\begin{array}{cc}\hfill v_m& \in {\mathbb{C}}_n,\hfill \\ \hfill {\mathbb{C}}_m& \ni v_n.\hfill \end{array}$$

(27)

This process is repeated for all clients in $\mathbb{T}$.

For the case that the client n succeeds to join the existing XC group or to create the new XC group, the client n becomes an element of ${\mathbb{U}}_X$, which is a set consisting the clients in XC groups. Finally, the clients who are not included in either ${\mathbb{U}}_L$, ${\mathbb{U}}_M$, or ${\mathbb{U}}_X$ are included into ${\mathbb{U}}_U$ and will be served by UC through separate connections. The proposed video streaming scheme using XC is explained in detail in the Algorithms 1 and 2.

Algorithm 1 Proposed Video Streaming:

Phase 1. LC and MC

1: Initialization:

2:   ${\mathbb{U}}_L=\varnothing ,{\mathbb{U}}_M=\varnothing$          ▹ Sets of clients

3:   ${\mathbb{G}}_M=\varnothing$          ▹ Set of MC groups

4: Obtain a set of candidate clients for LC:

5:   $\mathbb{T}=\{1,\dots ,N\}$

6: for $n\in \mathbb{T}$do

7:     if $v_n\in {\mathbb{C}}_n$ then

8:       ${\mathbb{U}}_L={\mathbb{U}}_L\cup \left\{n\right\}$

9:     end if

10. end for

11: Obtain a set of candidate clients for MC:

12:   $\mathbb{T}=\{1,\dots ,N\}\backslash {\mathbb{U}}_L$

13: while$\left|\mathbb{T}\right|>0$ do

14:     $u=\mathbb{T}\left[0\right]$

15:     $S=\varnothing$

16:     for $m\in \mathbb{T}$ do

17:       if $v_u==v_m$ then

18:         $S=S\cup \left\{m\right\}$

19:       end if

20:     end for

21:     if $\left|S\right|>=2$ then

22:       ${\mathbb{G}}_M={\mathbb{G}}_M\cup \left\{S\right\}$

23:       ${\mathbb{U}}_M={\mathbb{U}}_M\cup S$

24:       $\mathbb{T}=\mathbb{T}\backslash S$

25:     end if

26: end while

Algorithm 2 Proposed Video Streaming:

Phase 2. XC and UC

27: Initialization:

28:   ${\mathbb{U}}_X=\varnothing$          ▹ Set of clients

29:   ${\mathbb{G}}_X=\varnothing$          ▹ Set of XC groups

30: Obtain a set of candidate clients for XC:

31:   $\mathbb{T}=\{1,\dots ,N\}\backslash {\mathbb{U}}_L\backslash {\mathbb{U}}_M$

32: $cnt=0$

33: while $cnt<\left|\mathbb{T}\right|$ and $\left|\mathbb{T}\right|>0$ do

34:     $cn{t}^{++}$

35:     $u=\mathbb{T}\left[0\right]$          ▹ A client to check for XC.

36:     if $|{\mathbb{G}}_X|>0$then          ▹ XOR group already exists.

37:       for $S\in {\mathbb{G}}_X$do        ▹S is a set.

38:         $j=\mathrm{True}$

39:         for $s\in S$ do

40:           j *= $(v_u\in {\mathbb{C}}_s)\ast (v_s\in {\mathbb{C}}_u)$

41:         end for

42：        if $j==\mathrm{True}$ then

43：           $S=S\cup \left\{u\right\}$      ▹ Client u is added into S.

44：           ${\mathbb{U}}_X={\mathbb{U}}_X\cup \left\{u\right\}$

45：           $\mathbb{T}=\mathbb{T}\backslash \left\{u\right\}$

46：          break

47：        end if

48：      end for

49：    end if

50:     if ($|{\mathbb{G}}_X|==0)$ or $(j==\mathrm{False})$ then

51:       for $s\in \mathbb{T}\backslash \left\{u\right\}$ do

52:         if $(v_u\in {\mathbb{C}}_s)\ast (v_s\in {\mathbb{C}}_u)$ then

53:           ${\mathbb{G}}_X={\mathbb{G}}_X\cup \left\{\{u,s\}\right\}$     ▹ A new group of XC

54:           $\mathbb{T}=\mathbb{T}\backslash \{u,s\}$

55:           ${\mathbb{U}}_X={\mathbb{U}}_X\cup \{u,s\}$

56:           break

57:         end if

58:       end for

59:     end if

60: end while

61: ${\mathbb{U}}_U=\{1,\dots ,N\}\backslash {\mathbb{U}}_L\backslash {\mathbb{U}}_M\backslash {\mathbb{U}}_X$

4. Numerical Results

In this section, the performance of video streaming scheme using XC is analyzed in terms of average connections required to serve each client’s video play, and compared with that of a conventional scheme without XC. Let $\kappa$ denote the number of the required connections of the video streaming schemes. For the proposed scheme using XC, $\kappa$ can be calculated as

$${\kappa }_{\mathrm{prop}}=|{\mathbb{G}}_M|+|{\mathbb{G}}_X|+|{\mathbb{U}}_U|,0\le {\kappa }_{\mathrm{prop}}\le N.$$

(28)

For the conventional scheme without XC, we need to allocate a dedicated connection to every client in ${\mathbb{U}}_X$. Thus, $\kappa$ for the conventional scheme can be calculated as

$${\kappa }_{\mathrm{conv}}=|{\mathbb{G}}_M|+|{\mathbb{U}}_X|+|{\mathbb{U}}_U|,0\le {\kappa }_{\mathrm{conv}}\le N.$$

(29)

Please note that ${\kappa }_{\mathrm{prop}}\le {\kappa }_{\mathrm{conv}}$ is always satisfied because $|{\mathbb{G}}_X|\le |{\mathbb{U}}_X|$ and $|{\mathbb{G}}_X|=|{\mathbb{U}}_X|$ is only valid when $|{\mathbb{G}}_X|=|{\mathbb{U}}_X|=0$. We define the average normalized load as the average number of required connections per each client’s video view, which is denoted by $\eta$ and can be calculated for the proposed and conventional schemes, respectively, as

$$\begin{array}{cc}\hfill {\eta }_{\mathrm{prop}}& =\sum _{n=0}^N\frac{n}{N}\times Pr[{\kappa }_{\mathrm{prop}}=n],\hfill \\ \hfill {\eta }_{\mathrm{conv}}& =\sum _{n=0}^N\frac{n}{N}\times Pr[{\kappa }_{\mathrm{conv}}=n].\hfill \end{array}$$

(30)

All numerical results were obtained through mathematical analysis given in Section 3.1 and verified by Monte-Carlo simulations using a Python-based simulator. In the figures, the lines and markers denote numerical results from mathematical analysis and Monte-Carlo simulations, respectively. In simulations, the number of iterations for averaging the effect of many random variables is 100,000.

Figure 5 shows the average normalized load $\eta$ of the proposed streaming scheme using XC and the conventional scheme without XC for various values of cache length. The numbers of clients and video contents are given by $N=2$ and $V=20$, respectively, and the parameter $\alpha$ of Zipf distribution for contents’ normalized popularity is 0, 0.5, 1.0, or 1.5. The figure shows that our numerical results obtained by mathematical analysis are consistent with those from simulations. The proposed and conventional schemes can both reduce the average load as the parameter $\alpha$ of Zipf distribution increases. As $\alpha$ increases, the deviation of popularity among contents is expanded and thus every client is more likely to play the popular contents, which indicates that the probabilities that the popular contents are cached increase while the probabilities that less popular contents are cached decrease. As a result, an increasing $\alpha$ can reduce the average normalized load because the hit probability, which is the probability that the contents to play are cached in their own caches, increases. As the length of cache, C, increases, the probabilities that contents are cached increase regardless of popularity. Thus, for given $\alpha$, an increasing C also reduces the average normalized load. To be more specific, when $\alpha =1.5$ and C increases from 1 to 5, the average normalized load decreases from 0.7 to 0.3 for both proposed and conventional schemes. In this figure, although the proposed scheme using XC outperforms the conventional scheme without XC, the gap of the performance is marginal, because when the number of clients is small $(N=2)$, the frequency of using XC decreases and hence, the gain achieved by XC is limited.

In Figure 6, we compare the performance of the proposed scheme to the conventional scheme according to the number of clients, N. Figure 6a shows the average normalized load of the proposed and conventional schemes by varying N from 2 to 10 when $V=20$, $C\in \{1,2,3,4,5\}$ and $\alpha =0$. Here, $\alpha =0$ means that Zipf distribution become Uniform distribution and all video contents thus have the same popularity. As N increases, the frequency of using MC for the conventional scheme and the frequency of using MC or XC for the proposed scheme both increase. Thus, the average normalized load decreases with an increasing N for both the proposed and conventional schemes, as predicted in Figure 5. In addition, the average load also decreases with an increasing C because the frequency of using LC for the conventional scheme and the frequency of using LC or XC for the proposed scheme both increase as C increases. Figure 6b shows how much the proposed scheme can reduce the average normalized load by using XC, compared to the conventional scheme. The percentage of average load reduction by the proposed scheme is calculated as $\zeta =\frac{{\eta }_{\mathrm{conv}}-{\eta }_{\mathrm{prov}}}{{\eta }_{\mathrm{conv}}}\times 100[\%]$. In this figure, we can observe that for all N and C values, the proposed scheme outperforms the conventional scheme due to the gain obtained from XC, and thus $\zeta >0,\forall N,C$. The frequency of using XC in the proposed scheme increases as N or C increases and thus, $\zeta$ increases with increasing N or C. As a specific example with $C=5$ and $N=10$, the proposed scheme can reduce the average load about $18\%$, compared to the conventional scheme.

In Figure 7, according to N, we plot the average normalized load in Figure 7a and the percentage of average load reduction, $\zeta$, in Figure 7b, respectively, when $V=20$ and $C\in \{1,2,3,4,5\}$. In this figure, $\alpha$ is set to $1.0$ to let all videos have different popularity from each other. For the case of $\alpha =1.0$, the frequency of viewing top three out of 20 videos accounts for about $50\%$. The average normalized load is reduced more for both proposed and conventional schemes as $\alpha$ increases from 0 to $1.0$, as shown in Figure 6a and Figure 7a. As $\alpha$ increases, the deviation in popularity among video contents increases, which can yield the same effect as increasing N or C. By comparing Figure 6a and Figure 7a, we can observe that as $\alpha$ increases from 0 to $1.0$, the average load of the proposed scheme decreases from $0.523$ to $0.39$ when $C=5$ and $N=10$. In terms of the percentage of average load reduction, by comparing Figure 6b and Figure 7b, we can observe that $\zeta$ is determined by C and N as well as $\alpha$. For the case of $N=10$, when C is relatively large, e.g., $C=5$, $\zeta$ decreases from $17.8\%$ to $15.3\%$ as $\alpha$ increases from 0 to $1.0$. In this case, however, when $C=1,2,$ or 3, $\zeta$ with $\alpha =1.0$ is greater than $\zeta$ with $\alpha =0$ for most N values. For example, when $C=3$ and $N=5$, $\zeta$ increases from $5.5\%$ to $7.3\%$ as $\alpha$ increases from 0 to $1.0$. In the proposed scheme, LC and MC are given a higher priority than XC. Therefore, as C, N, and $\alpha$ all increase, the probability of using LC or MC increases and the gain achieved from XC decreases slightly. Even though we used small values for N, V, and C to simplify computer simulations, the proposed scheme can be applied to real large-scaled video stream systems.

5. Conclusions

A streaming server can process requests from multiple clients simultaneously by coding the bit streams requested from the multiple clients with XOR operation and multicasting the coded bit stream to the multiple clients. Each client can recover its content from the coded bit stream with XOR operation using contents stored in its cache, which is based on zero-identity and self-inverse properties of XOR and can reduce the number of transmissions by dealing with the requests simultaneously. Existing studies on the data transmission using XOR-based coding mainly focused on theoretical analysis or optimal coding in limited environments, and most of them were thus less feasible. In this paper, we investigated how the data transmission using XOR-based coding could be applied to video streaming systems without interfering existing video streaming methods such as UC, MC, and BC. We first modeled the behavior of video contents in clients’ caches as a Markov chain, and derived the caching probability that a video content has been already cached in the client’s cache when a client wants to play the content at an arbitrary moment. We also proposed a new video streaming scheme for supporting XC while guaranteeing a backward compatibility with the conventional video streaming methods. With a simplified case of two clients, the basic concept of the proposed scheme was described, and the performance of the proposed scheme mathematically analyzed in terms of average normalized load. All analytical results were verified by computer simulations. Then, the proposed scheme was extended to a complete algorithm that can support multiple clients more than two. Our numerical results showed that the proposed scheme using XC outperforms the conventional scheme without XC in all situations and the performance enhancement of the proposed scheme becomes more noticeable as the number of clients or the length of cache increase. For a specific situation with $C=5$ and $N=10$, we showed the proposed scheme can reduce the average load about 18%, compared to the conventional scheme.